Begin implementation of direct backend manipulation

Both daemon and client will use the same methods to directly manipulate
backends, however only root may do this in the case of the client. Otherwise
they are required to use the wire protocol.

This code is meant to demonstrate how we could handle various backends,
but will require new initialisation code to read all layers from their
configuration files, so that we can load a backend dependent on the
layer configuration.

The gdbm module (and all future modules) should have a Hashmap containing
the layer as the key, and their specific implementation (GDBM_FILE) as
the value, allowing us to restrict module use to one instance per format.

systemd cleanup macros should also be imported to ensure static variables
are appropriately cleaned up. Alternatively we may rely on atexit type
helpers.
Use BuxtonClient instead of struct BuxtonClient

We already typedef BuxtonBackend for improved readability, BuxtonClient
should also adhere to this convention.
Add skeleton for memory backend

Memory backend will be used as the primary test for further backend
implementation within Buxton, and will cause various API changes to
ensure the system is well integrated.

The following commits will have to restructure the existing API to
make backends unaware of explicit datatypes, migrating to set/get
value methods, typed via struct/union keys.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Add Buxton data types

This commit adds the basic data types we will use in Buxton. There will be
no get/set_string type methods, just get/set_value, using the data struct
BuxtonData.

In order to use BuxtonData, you must set the BuxtonDataType to a valid type
such as string:
    BuxtonData data;
    data.type = STRING;

It is not desirable for backends to explicitly handle types, they should
store and return data per the requests in libbuxton. Buxton will then handle
sanity and verification of data + types.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Move to get/set_value methods and drop old string specific code

Buxton will no longer have type-specific methods for manipulating data,
rather it will use the BuxtonData struct to allow backends to just store
and retrieve data, leaving the decisions to Buxton.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Add default configuration file location to config.h

On startup we'll have to discover all available layers that have been
configured on the system, before we can load relevant backends.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Do not check euid in buxton_direct_open

The symbol is only usable from libbuxton and is not publicly exported,
therefore only programs and libraries built in tree can access this method.
Also, we'll eventually be running as the 'buxton' user which will not have
euid of 0.

Also fixed a small issue whereby _directPermitted may still not be
initialised when buxton_client_get_value has been called, which is
an error.
Start to implement configuration loading

Following commits will flesh out this code and implement the actual
configuration (layer names, smack labels and database modules).

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Implement --direct option in buxtonctl (cli)

The root user may use the --direct option to directly manipulate
values in buxton layers in the very same way that the buxton daemon
will.

This must be the very first option to buxtonctl, and the user must
have the euid of 0 to use this. For example:

   buxtonctl --direct set-string resource key value

In the future, it will only be possible to use the --direct option
from within packaging scripts from vendor and when the daemon is
offline.

Signed-off-by: Michael Ikey Doherty <michael.i.doherty@intel.com>
Update TODO: --direct is implemented
data: Add default configuration file

Also add parser cflags and ldflags to libbuxton.
A more detailed config file example.