Add Gemfile to capture dependencies for the application

In development, just use it to install the gems we depend on for testing; this
is as normal.

For production, this may be used if we ever have non-core gem dependencies.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Documentation for the new EL MK Razor Client code

This updates the readme with various notes about the new MK client code, and
how it works.  The focus is on ensuring that folks can get some value out of
the system immediately, mostly to aide other developers.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Define, and test, fetching the 'hardware ID' of the machine

This implements the classic Razor conception of a machine hardware ID, based
on the order of reported MAC addresses for network cards that happen to be
named like the default Linux convention for kernel-discovered Ethernet cards.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the 'MK::Config' abstraction for fetching configuration

This hides the gory details of the configuration priority and parsing away
from the rest of the system.  It implements a simple case-insensitive keyed
hash-like interface to access configuration values.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add `facts` and `user_agent` properties to the node

These provide a mechanism to access the facts, and the user agent, data for
the current node.  These ensure that required configuration data is gathered
in a central location, rather than open-coding it in each consumer location.

For the moment the facts are simply the Facter facts, directly reported; we
have no custom configuration or exclusion.  In future, if we require those
changes this ensures there is one place, and only one place, to change that.

The user agent support gathers various version numbers to form the HTTP user
agent header -- and to allow the server to have a reasonable view of the state
of clients that are communicating with it.  As more tools or packages that
Razor depends on are added to the system, this can be extended to continue to
report the relevant information to allow the server to make decisions on next
required actions.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the command line dispatcher and registration script

This puts in place a command line dispatcher for "script" actions, and starts
to build the high level "register" action.  This captures the high level logic
flow of registration in a single process.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the `register` command, and supporting code

This implements the `register` command, to submit data about the node to the
Razor server, and to handle the response which includes the next operation.

Presently, all functionality is present and correct other than the response
handling -- currently, stubbed out as the infrastructure to process commands
is not yet present.

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