(maint) Fix install module acceptance test on precise

Without this patch the `with_modulepath.rb` acceptance test is failing
on Ubuntu 12.04.  The cause of this problem is that `puppet apply` is
being used to purge the `/etc/puppet/modules2` directory, which doesn't
appear to be working as expected.  This itself is concerning, but the
concern is unrelated to the expected behavior expressed in the test.

This patch addresses the problem by simply using `rm -rf` to purge the
acceptance test instead of using `puppet apply`.
(#7224) Fix hostname does not match on Ubuntu 12.04

Without this patch Puppet does not improve upon the `hostname does not
match the server certificate` error message coming from OpenSSL.  The
root cause of this problem is a bad regular expression that matches on
`error.message =~ /hostname (was )?not match/` when the error message on
precise is actually `"hostname does not match the server certificate"`

This patch addresses the problem by allowing any word to optionally
exist between `hostname` and `not` in the error message.
(maint) Improve failure message
(maint) Fix enc_provides_node_when_storeconfigs_enabled on precise

Without this patch the enc_provides_node_when_storeconfigs_enabled is
failing on Ubuntu 12.04 LTS with MRI 1.9.3-p0.  The root cause of the
failure is that the ENC script used does not output valid YAML data,
it's lacking the `--- ` header.

This patch addresses the problem by using `Hash#to_yaml` to produce
valid YAML output for the ENC API.
Merge branch 'stable_precise_acceptance' into stable

* stable_precise_acceptance:
  (maint) Fix enc_provides_node_when_storeconfigs_enabled on precise
  (maint) Improve failure message
  (#7224) Fix hostname does not match on Ubuntu 12.04
  (maint) Fix install module acceptance test on precise

closes #1624
(#20447) Wait for server to shutdown before exiting daemon

Previously, if the filetimeout was set to 0 and the puppet master was
run, the master would exit immediately. This was caused by the scheduler
having nothing to do and the new logic for it causes it to stop running
at that point (because once there is nothing to do, there is also no
chance that something will cause it to having something to do). There
was a slightly wrong assumption that was being made for that logic: the
scheduler is in control of all activity in the daemonized process. This
is not the case.

The daemon has 3 parts to it:
  * configuration reparse
  * agent runs
  * server control

The server does not take part in the scheduler inside the daemon. It is
assumed to be a separate thread/process, which the daemon will kick off
when it starts, and stop when the daemon is told to stop. When the
"start" method of the daemon exits, the daemon itself exits and the
server will be required to shut down.

There are 2 ways that could be used to solve this problem: have the
scheduler sit in a busy loop (or sleep forever) when it has nothing to
do, or wait for the server to finish before the daemon considers itself
done. This commit uses the latter option.

The new code will wait for the server to finish before the Daemon#start
method returns. This makes the dependency explicit rather than hidden in
an infinite loop in the scheduler.
(Maint) Inject Pidlock dep into Daemon

While trying to understand several different code paths in the
Puppet::Daemon code the realization that the tests for the daemon code
had to mock internal methods on the class under test caused me worry. By
removing the mocking of the internal methods it was obvious that there
was another collaborator that is a locking service at play. Services
should normally be injected into, and not created by, the consumer of
the service.

This injects the Puppet::Util::Pidlock into the Daemon and reworks the
points of construction of Daemon objects so that the correct information
is available at the point of construction. This require moving the
Daemon creation from the preinit methods to the setup or run methods in
order to ensure that command line processing and therefore Puppet#[] was
ready at the point of construction so that the correct Puppet[:pidfile]
could be used.
(Maint) Inject scheduler into Daemon

By injecting the scheduler into the Daemon we can provide a different
one during testing that allows us to cleanly check what the jobs are
that the Daemon will be running.
(Maint) Clean up Daemon tests

The Daemon tests were relying on a lot of instance variables and stubing
the class under test. This removes that.
(Maint) Remove unused register code for Server

The Puppet::Network::Server class seems to have atrophied over time.
There are multiple redundant or unused code paths in it.

This commit removes the "registration" facility for the network server
to handle certain indirections. There were no users of these outside of
the tests and there is no functionality that they provided. The only
thing the registration of indirection names did was check to see if such
an indirection existed. I believe that at one point these had been meant
to act as a per-server handling facility (as indicated by one of the
test names), but they no longer serve such a purpose.
(Maint) Remove duplication btwn Daemon and Server

The Puppet::Network::Server had a lot of the same code as the
Puppet::Daemon (closing filehandles, managing a pidfile for locking).
There was a comment in the Server class that indicated that it was not
even clear if the duplicate code was being used.

It turns out that the code was being used, but was incorrect. By turning
on debug and watching the log output of the master, you were able to see
that the close_streams was happening twice, as you would expect by
following the code paths. There is no need for this to happen. In
addition the pidfile is managed twice. This was discovered by
instrumenting the code with a debug statement and noticing that the
pidfile was locked 3 times (one from the server, one from the daemon,
and one more from an unclear location).

Removing all of this turns Puppet::Network::Server into a simple wrapper
around the WeBrick code, reduces the overhead for daemonizing, and
clarifes the pid as lockfile ownership.
(Maint) Mark the Puppet:Daemon private

The Daemon code is an internal implementation of how we create our
master and agent processes. Others should not rely on it. This also
hides some of the internal handling methods (for managing the pidfile).
(Maint) Document Puppet::Daemon

The Daemon code is getting better, but is still not the clearest thing
in the world. This adds some class documentation that tries to clarify
the parts of the daemon.