The template code that processes also_notify is of a kind with the checks and
processing of other optional smart-array values. Make its default an empty
string so that the clause may be properly omitted from a config that doesn't
use it.
`Socket.ip_address_list` is a new addition to ruby 1.9. Maintain support for
ruby 1.8.7 by making the new autorequire feature of `resource_record`
conditional on the existence of the required API.
The changes in the `redhat-default-zones` branch, when released, may cause
upgrade difficulties for Red Hat system administrators. Try to ease the
transition.
`bind::defaults::supported` should always have a boolean value. If it does not,
then this means either 1) user error (e.g. the user defined some other value
for the key) or 2) module_data is not functioning correctly.
The `params` vs. `bind` class distinction has been blurry for a long time. I'm
formalizing it.
`params` is now `defaults` and its purpose is to gather platform-specific
variation into a single scope. These variables are related to situating a BIND
server on a particular platform and it should not ever be necessary or perhaps
even possible to change them as a matter of preference. Rather, correct values
are function of e.g. `$osfamily` or `$operatingsystem`.
The parameters of the `bind` class are limited to those that control the
server's feature set. These parameters *are* matters of preference and/or
purpose, rather than platform.
Also, I have taken some care to develop a convention for direct references to
qualified parameters where they are re-scoped into the local scope centrally at
the top first, and subsequent references are to the local value. This should
minimize future code churn and also aid readability.
Fix a bunch of warnings whne using the bind::updater class by moving confdir to
the params class. In order for this to work, the bind and bind::updater classes
both now inherit from params. Also, fix the default value for
managed_key_directory to something that's actually falsey.
