Adds the nrm/schemas repository which defines the communication schemas
for the upstream and downstream APIs. The messaging.py file now uses
decorators and two added python dependencies (jsonschema and warlock).
This commits also adds the .envrc direnv configuration file for
nix-based development.

Instances in singularity are basically the same as being able to create
an empty container and then run something in it, so we can have the same
thing as with nodeos.

One main issue with the code as is: we should probably refactor the
container_manager code to modify the manifest on the fly according to
the options listed in it. It would make it easy to pass along stuff like
PWD, necessary binds and so on.

If monitoring is active, make sure to export the
ARGO_NRM_DOWNSTREAM_EVENT_URI variable required by libnrm.

Fix #49.

The daemon can be configured to launch singularity containers. In such
case, the manifest must contain an image section.

Note that this doesn't support any resource management with singularity,
since that stuff is only available as root. We will add a second
container runtime option to support it later.

This catches the exception and sends a message on the log with
the ERROR level.

Make the container Popen pass the working directory from the `nrm
run` call, through the $PWD environment variable.

Fixes #31: refactor the code so that the ioloop is not install
forcefully, as zmq and tornado can work better now.

high-water marks, the mechanism used by zmq to avoid buffer bloat and
start dropping messages, has been causing all sorts of problems. Set all
of them to `infinite`, to avoid these issues.

Note that the recent changes seems to cause the messaging tests to
block, so we disable them for now.

Change the `wait_connected` method to a `connect` method with an
optional wait. Ensure that the actual connect call on the socket is done
after the monitor is created, otherwise the monitor might miss the
connection event.

Add a "monitoring" section to the manifest, that allows users to modify
libnrm through environment variables.

close_fds only defaults to true on python 3, leading to leaking open
file descriptors every time we fork a process.

BSD3, as discussed.

For some reason this seems to be triggering a leak of a open file
descriptor, even though it should be garbage collected.

As for why it's there...well there was a time when I had hoped of
implementing support for stdin.

pyzmq recommends the use of a single context for all objects in the same
application:
https://pyzmq.readthedocs.io/en/latest/api/zmq.html#zmq.Context.instance

More importantly, each context creates at least one thread, resulting in
a lot of threads with a lot of open file descriptors. This path reduces
that number by quite a bit.

Add a container runtime that doesn't create containers, but can still
launch commands.

That should make it possible, once we figure out how to change it in the
configuration, to actually run the NRM without a setuid binary.

Extract the container runtime interface from the container manager, and
use a hierarchy of classes to enforce a runtime interface that makes
sense.

This will allow us to create alternative runtime implementations without
major changes to the container manager code.

Missing checks in aci resulted in features absent from the manifest to
be counted as enabled.

Just to make it easy to debug binding issues.

!27 replaced the resource field of the `container` named tuple by a
dictionary. Restore the old type, a `resources` named tuple and make
sure to propagate this across all the code.

Refactor the container creation code to isolate the building/retrieving
of a container namedtuple out of the core container creation code.

This simplifies quite a bit the different branches of this code, and
makes the core create method almost entirely dedicated to just launching
a command.

Some of these commands prefix were in a bit of a weird order. In
particular, it makes sense to have perfwrapper at the end.

!27 caused the perfwrapper to only be activated for the command that
creates a container, and never for the other commands launched in an
already running container. This patch restore this feature.

The container creation code was starting to repeat the same logic for
testing that a container manifest was enabling a specific feature.

Instead we add a method to the image manifest to check for that.
Also adds tests for that feature.

The last merge changed the API visual style to increase readability.

The manual merging was not done in a proper way however, and some of the
changes from its previous merges were reverted. This commit fixes this.

This commit does two things:
- re-indents the message schema to be more readable
- lets `cmd listen --filter` print any incoming message, without
discriminating on container_uuid. This makes cmd listen usable until
a proper application_uuid management is written into nrm.

Some inconsistencies in the CI let a merge request go through without
stylechecking.

Made necesseary fixes required to make the aggregative downstream api
integration to work with the new downstream messaging layer.

Also,fixed the case where daemon crashed when an application message
(from libnrm using pmpi) was received after container was killed

run_policy on all containers removed as the controller no longer has
application manager info

Any other refactoring and fixes required (check merge request
discussion)

See Issues #13, #20 and Merge !41

Added support for pinning process/task to a core. This is important for
allowing the use of power policies that use contextual information from an
application phase and use it for computing frequency levels for the next phase.
In absence of process/task pinning, the contextual information obtained does
not serve any value as it is not representative of application phase behavior
on a core as the processes and task can migrate during the next phase.

See Issue #20

Fixes NRM not returning the first N resources (cpu and memory). This
is important for reproducibility and reducing variation

Fixed the interaction of the multi-node support feature (#17) with the new
messaging layer feature. Also, added any other fixes required to make the
libnrm work with the Aggregative downstream API

Adds support for aggregation of phase context information for an
application. The damper value (in nanoseconds in the manifest file)
decides the minimum phase length for which the phase context
information is sent to the NRM (implemented in 'libnrm' repo
[See Issue 2]). This will limit the number of msgs sent to the NRM.

See Issue #13

Refactored diff calculation code to work without needing changes in
coolr module (Patch for Commit 36401a84)