Template and task revamp

There was confusion around finding templates and tasks in cases of task inheritance. For one reason, tasks are referenced in their .yaml files by name, but are uniquely identified via name and os_version. Additionally, having the .yaml files separate from their respective template directory is counter-intuitive. Now, yaml files have a consistent name (metadata.yaml) and exist alongside their templates in one self-contained task folder.

Included in this changeset is:
- Removing os_version from path
- Adding ".task" to task folder name
- Using "metadata.yaml" as a taskname convention inside task folder
- Allowing "/" and preventing "$" in task names.

Fixes https://tickets.puppetlabs.com/browse/RAZOR-154
Add extra datatype integrity test

For https://tickets.puppetlabs.com/browse/RAZOR-135
Add "lower" & "upper" matcher functions

To facilitate case-insensitive string matching for instances like MAC addresses, functions "lower" and "upper" have been added to the matching language. This will allow, e.g. `["=", ["upper", ["fact", "macaddress"]], "F0:1F:AF:D8:F2:A6"]`

Fixes https://tickets.puppetlabs.com/browse/RAZOR-89
Fixing stock tasks

Some stock tasks required fixing due to the migration from RAZOR-154. This file movement means the user does not need to rename any tasks.
Link repo to task

The association between a repo and a task should not be indirect through the policy. Repo requires an association to task. Policy has an optional association to task, which will help with backward-compatibility.

Fixes https://tickets.puppetlabs.com/browse/RAZOR-143
Razor version string must not include a newline

An undetected bug meant that some razor versions could include a newline when
generating from git metadata.  This hadn't caused any practical problems until
we started using that as part of the etag for cache control.

This fixes the issue, and adds a test to try and catch this if it crops up
again somewhere.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement GET on commands returning JSON data

This implements the bones of the protocol to allow our client code to fetch
data about commands dynamically from the server.

https://tickets.puppetlabs.com/browse/RAZOR-183

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add generated help text to the command data

Now that we have a basic protocol for fetching data about commands, we can use
that to expose the documentation added to them to the world.  This commit adds
the basic infrastructure for rendering help text as markdown, and wires it up
to the public API.

https://tickets.puppetlabs.com/browse/RAZOR-183

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement a basic full help template

This adds a basic template to cover the help output, and extends our help DSL
to cover a few more details that this showed we needed.  This is hardly
optimal, but is a reasonable starting point for rendering the help text
for our commands.

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

The rename from "recipe" to "task" affected a few extra instances in preseed files.
Disallow empty key name for node metadata

The key in {"": "blank"} should not be allowed in any commands (e.g. modify-node-metadata) since it is not a meaningful attribute.

Fixes https://tickets.puppetlabs.com/browse/RAZOR-121
Disallow empty key names in hash

The key in {"": "blank"} should not be allowed in any commands (e.g. modify-node-metadata) since it is not a meaningful attribute. This commit includes cases where Array holds a Hash. Also including a fix for a few error messages that reference undefined variables.

Fixes https://tickets.puppetlabs.com/browse/RAZOR-121
Fixing spec tests

Fixes https://tickets.puppetlabs.com/browse/RAZOR-121
* Rakefile(db:nuke): add IF EXISTS to DROP TYPE statements

During development, it's easy to get the database in a wonky, half-created
state when things go wrong; without IF EXISTS db:nuke will fail if the type
it is trying to drop is not there.
Schema and model class for the command log

The command log will allow us to both store an audit trail of commands
issues against the server and use those commands to report status and
errors of background jobs connected to specific commands.
Add logic for creating (starting) and finishing commands

Razor::Data::Command.start is a convenience wrapper around creating a
command; store is a convenience around setting a command's status and
finished_at if needed.
Remove trailing whitespace

No functional change
Have all commands add an entry to the command log

Any successfully submitted command will now create an entry in the command
log, and the command specs check for that. For now, all commands will
pretend to be synchronous, and report a status of 'finished' when the
corresponding request ends.
Update command status for background tasks

For ISO import, we thread a command object through to the message
processor, tkaing care to pass it along to each stage of the import
process. The import process then updates the status of the command, in
particular marks it as 'running' as soon as it starts working on it, and
marks it as 'finished' when the last step of the import saga is done.

Most of the error reporting is done by our message processor - that is
crude, and better ways to report errors from within the actual processing
is the main reason why we try to pass the command to each stage of the
saga.

We can't demand that all background tasks have a command associated with
it: changing node metadata and tag rules spawn background jobs in
Node.around_save and Tag.around_save, where they do not have access to a
command object, nor does it seem desirable from the user's POV to treat
them as async commands. There may be a case to give the user an indication that the database has settled after these changes, but that is unlikely to change the general situation that we'll have background work that is, to the user, part of their command, and some that isn't.

The way the command is threaded through all over the place is a bit clumsy;
an alternative would be to have the messaging plugin define a 'command'
method that returns the command associated with the operation if there is
one, and methods that are called during async processing can access it that
way to e.g. report errors or update the status
Add a command collection to the API

Provide the standard means for listing all commands (in descending order of
submission) and to get the details about a specific command.

This commit finishes the fix for https://tickets.puppetlabs.com/browse/RAZOR-7