(#19349) puppetdb-ssl-setup should be choosey when it changes things

This patch modifies puppetdb-ssl-setup so it is more choosey when it changes
items in jetty.ini. In the past it would simply overwrite all settings, but
now you need to supply -f if you want to do this. This means that during
package upgrade we are passive for settings that have already been set, but
we do return warnings to the console so users can make these changes
themselves if they so desire.

However, there are cases where this kind of thing is required - esp. during
first installation so the tool now looks for factory default settings and
modifies those if it finds them. These are in the form:

    # setting = <FOO>

Our tool looks for these especially, assuming they are package defaults and
_will_ modify them regardless of the -f setting. Once they are modified it
shouldn't do it again. This makes sure the 'initial installation' case does
the write thing.

The original jetty.ini file that is laid down now has all the SSL settings
commented out and in the format the tool requires. The fact they are commented
means that if the tool bombs out PuppetDB should still work but with no SSL
settings.

I've made the script more wordy about what it is doing which might help, and
also made sure we backup the old jetty.ini before doing anything. The backup
itself is timestamped, so subsequent runs on a faulty jetty.ini do not
override somethings settings no matter how often it runs. Generally I hate it
when tools don't do this, so I don't want to inflict it on our users.

The scriptage around change settings has been made more generalised so we can
stretch this pattern out to a number of settings if required now.

Acceptance tests have been added as well, to test for idempotency and to also
test the -f functionality.

Signed-off-by: Ken Barber <ken@bob.sh>
Add -h option and usage to puppetdb-ssl-setup tool

Signed-off-by: Ken Barber <ken@bob.sh>
Remove extraneous "this" from func docs

Signed-off-by: Ken Barber <ken@bob.sh>
lein shouldn't fail when "rake version" fails

The current use of "rake version" in the project.clj breaks all use of
leiningen, even for non-packaging tasks, if you don't have all the
packaging machinery installed.

There are a few problems with this:

1) There is no documentation in our repo about how to actually do
development on the clj code now. I updated to master, and couldn't run
anything and had no idea how to proceed. New contributors or people
building from source (of which there are definitely a few) would have
even more trouble. I just gave 2 public talks on PuppetDB, and now any
people checking out our stuff will have a bad time. :(

2) It's a suboptimal experience for developers. To do anything with the
project, like run "lein test", "lein compile", "lein repl", or even
"lein help" you now need to have rake & facter installed, and have run
the packaging tasks. This is all for packaging machinery that has no
relation to the actual task the developer was trying to complete in many
cases, which is somewhat confusing.

3) It makes integration into IDEs and editors that manage the use of
lein for you considerably more difficult. For one, you now have to bake
into all of those tools the knowledge of how to launch rake, where the
facter libs are, etc (difficult if you're using, say, rvm). Some tools
like drip don't even give you the option.

This fix is pretty basic; if "rake version" fails for whatever reason,
we default to a hard-coded version string that indicates that this is a
development build. This allows developers to interact with the clojure
codebase as they normally would, while still allowing us to do much more
interesting stuff for formal packaging purposes.
Merge pull request #473 from kbarber/ticket/master/19349-puppetdb-ssl-setup_no_override_during_upgrade

FOR > 1.2.0 (#19349) puppetdb-ssl-setup should be choosey when it changes things
Merge pull request #484 from kbarber/maint/master/this

Remove extraneous "this" from func docs
Merge pull request #485 from grimradical/version-fix

lein shouldn't fail when "rake version" fails