Change how create-policy maintains order of policies

The previous scheme of explicitly exposing users to the rule_number is very
cumbersome. It's more intuitive to allow users to not specify an order and
default to appending new policies, and if they do want to control order, do
that by expressing before/after which policy the new policy should go.

Fixes https://github.com/puppetlabs/razor-server/issues/137
Command move-policy: move a policy before/after another one
Policies can seed metadata on nodes

  - A policy can add metadata to the nodes that bind to it.
  - This happens in a non-destructive manner as the policy will only
    add metadata keys that do not already exist.
  - The commands update-node-metadata and modify-node-metadata now
    have a no_replace option that enables the non-destructive behaviour.
Add node power state management to Razor

This extends the IPMI system from passive monitoring of power state to active
enforcement: users can now declare the desired power state, and when that is
out of sync Razor will use the IPMI system to toggle to the correct state.

It also updates the database to use a custom type for power state tracking,
which means you get `on` or `off` nodes, rather than booleans with
unclear significance.

Finally, it makes an (ABI breaking) change to the layout of the node object,
moving power state out into a distinct object and exposing all the data
we have.  Especially, this exposes *when* the last power state update
happened, so users are hopefully less likely to mistake this for a real-time
statement of fact.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
* lib/razor/view.rb (node_hash): only include power information if there is any
Add a policies collection to brokers and include it in the broker details
* app.rb: turn off Sinatra's pretty exceptions

In development mode, Sinatra by default generates a detailed error
page. Since Razor is mostly used from the command line, these detailed
errors are unintelligible on a console and only lead to useless spew.
* Rakefile (db:nuke): also drop the power_state type

Otherwise, recreating a database doesn't work; this is all annoyingly
fragile and we need a better strategy for recreating the database, ideally
without resorting to drop + create database since that is highly annoying
in development.
Add a delete-broker command

Fixes https://tickets.puppetlabs.com/browse/RAZOR-87
Add a Puppet PE broker to Razor

This adds support for setting up a Puppet PE agent node using the new
"frictionless install" tools provided as part of a forthcoming PE release.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
README.md (microkernel): point to generic microkernel-latest.tar link

We were pointing people at the outdated microkernel-001; the -latest link
will make sure people always get the very latest.
* bin/razor-admin: drop the power_state type

Without that, reset-database will not return the database to a pristine
state and the following creation of the schema will fail.
Rename 'recipe' to 'task'

The word 'recipe' is used by other tools (e.g., Chef) for things that
aren't quite the same as what we are talking about in the context of Razor;
to avoid confusion, we are renaming recipes to the more generic word
'task', which still captures that this is about performing some sort of
work against nodes.

This is a follow-on to the renaming of installers to recipes in commit
a9f81b5f and mirrors that closely.
PE broker: rename 'latest' link to 'current'

The PE installer team decided to rename the link, and we follow suit
reinstall-node: produce some output for unbound, not installed ndoes

If a node exists, but requires no action for reinstall, we sued to not
return any human-readable message. We now do.

Fixes https://tickets.puppetlabs.com/browse/RAZOR-82
Version 0.13.0
Check for `/etc/razor/config.yaml` also

This updates the system to check for a config file under `/etc/razor` before
the one embedded in the razor root.  This is, generally speaking, going to be
the more correct location for configuration.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement Puppet Labs packaging infrastructure

This is all support data and files for our internal packaging toolchain --
while you can use this from the outside, it isn't super-focused on
enabling that.

Both RPM and Debian packages are supported.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>