Add command-specific spool config settings

This commit only modifies the configuration settings code.  It
allows the definition of new `[facts]`, `[catalogs]`, and
`[reports]` settings in the `puppetdb.conf` file.  Each of these
sections supports a boolean setting named `spool`; these settings
will be used to control whether or not PuppetDB commands are spooled
to disk before submission and retried after failures, but this
commit does not implement that functionality yet.

The default for the `spool` setting is `true` for reports, and
`false` for catalogs and facts.
Reorganize Utils::Puppetdb module a bit

This just makes sure that the correct methods are public/private
and groups class vs. instance methods appropriately.
Add support for retrying commands

This commit adds the logic (and tests) for spooling commands to
disk and retrying them later if they fail.
Refactor: introduce Command class

This commit moves all of the logic about commands (formatting, spooling)
into a new class called Command.  This way, the main "PuppetDB" util class
only needs to contain the logic about submitting / flushing the commands.
Better separation of concerns, and tests are able to focus on more atomic
business logic.
Refactor: create Config class

This commit breaks all of the configuration-related logic out of
the 'util/puppetdb' class and puts it in a new class called `Config`.
This is a better separation of concerns and makes the test files
for the two classes a little easier to read and maintain.
Add a maximum number of failures to the flush_commands method

In cases where PuppetDB has been down for an extended period of
time, you could end up with a large number of commands queued for
delivery.  Without some kind of maximum retries limitation, then
as long as PuppetDB remains down, every agent run that comes into
the master would cause PuppetDB to retry every single command that
was still in the queue.  Depending on how quickly the attempt to
connect to PuppetDB times out, this could cause huge performance
issues on the puppet master.

This commit adds a failure limit (currently hard-coded to 3) to
the command flushing logic.  Thus, if we try unsuccessfully to
flush 3 queued commands to PuppetDB, we'll stop trying until
the next time a flush is triggered.

Eventually we may want something even a bit more sophisticated
than this; this implementation will still cause 3 attempts on
every single agent run for the duration of the PuppetDB downtime.
We could build on this implementation by capturing a timestamp of
the last time that we encountered the maximum number of failures,
and don't retry again for a certain amount of time (5 minutes?)
after that.
Change spool/queue settings to 'max_queued_commands' approach

This commit does the following:

1. Get rid of the per-command configuration settings around
   queueing/spooling, because it really doesn't make sense to
   deal with them individually.
2. Added a `supports_queueing?` method on Command; currently,
   only Report commands support queueing.
3. Added a `max_queued_commands` setting.  If an action triggers
   a command enqueue operation and we've exceeded our max
   queued commands limit, we fail out.  Default value is 1000.
4. Minor cleanup to Config class.
Change `submit_command` to an optimistic queueing strategy

Prior to this commit, the `submit_command` method would always
enqueue any queueable command immediately upon receipt--before
attempting to send it to puppetdb.

This commit changes the behavior to an optimistic approach, where
we assume the command will be submitted to PuppetDB successfully
and therefore we only enqueue the command if it fails.
`flush_commands` should stop looping upon first failure

Prior to this commit, `flush_commands` was written to allow up to
3 command submission failures before it gave up and stopped trying
to process additional commands.  This commit changes it to give up
after the first failure it encounters.
Change command queueing to ensure FIFO

This commit makes a slight tweak to the command queueing logic that
ensures we get first-in, first-out behavior.  (We basically accomplish
this by prefixing a timestamp at the beginning of the spool file
names, and then making sure that the iterator method sorts the
spooled files by their names before loading them.  I initially tried
to just use the file mtime but there was not enough precision.)
Minor cleanup to Command class

This basically creates a second constructor for instantiating a
Command from a file, so that the class method `load_command`
didn't need to call a private method on the instance.  This
also gets rid of the options hash from the original constructor.
Refactor to support 'puppetdb retry' face/action

This commit moves the command submission logic into the Command
class, so that it is now entirely self-contained and no longer
has any dependencies on the indirector.  It also introduces a
Face called `puppetdb`, with a single action, `retry`, which
can be used to retry any failed PuppetDB commands that are
queued.
Rename face action, minor cleanup

* Rename the puppetdb face action from `retry` to `flush_queue`
* Minor cleanup in config class
* Add a basic test for the face
Cleanup in response to pull request comments from dpittman
Add some docs and comments about thread safety to the Command class
Add acceptance test for retrying commands

This adds an acceptance test which causes some intentional
command submission failures, verifies that they are queued
to disk, runs the puppetdb face to flush the queue, and
verifies that they were flushed successfully.
Remove all of the code and tests related to queueing commands
Merge pull request #377 from cprice-puppet/feature/master/retry-commands

Feature/master/retry commands