Migrate to a separate "command" class

Commands were previously defined with a trivial DSL in the app.rb file, which
worked reasonably well while we had a fairly small and simple set of commands.

With the addition of a validation framework, though, this began to get
cumbersome, and as we extend the set of features that are "about" commands,
rather than commands themselves (eg: help, documentation, browsing), this
becomes harder and harder to keep sensibly structured.

The goal of this series of changes is to move away from a single file
definition into something more, well, OO-based: a single class per command,
defining the basic behaviour of an individual request.

This also allows us to attach metadata about the command to the same place,
such as schema definition for validation, help generation and text, and
so forth.

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

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Validate `move_policy` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `add_policy_tag` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `remove_policy_tag` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `modify_policy_max_count` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `update_node_metadata` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `remove_node_metadata` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `modify_node_metadata` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Implement help text DSL for commands

This adds a new DSL for defining help text on commands.  The `summary`,
`description`, and `examples` commands at the class level attach parts of the
documentation to the command object itself.

While these presently allow us to attach the documentation and provide no
mechanism to communicate it to the user, they are the basis for building that
facility and allow us to work in parallel on building and presenting the docs.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
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