Mechanism for associating metadata attributes to objects

Existing use cases for metadata attributes:
* Security/Access control attributes.
* User-defined attributes, which can include any CRDT type.

It makes sense to represent metadata attributes as CRDTs and store them in the datastore.

Design options:

Option 1
-------
Store each metadata attribute as a separate object, associated with the data object through their keys:
The key format can be `object_key separator attribute_name` where:
* `object_name`: is the object's key
* `separator`: is be a character such as `/` or `.`. Different separators can be used to distinguish between attributes that can be directly referenced by users, and system attributes, not directly accessible by users (ACLs).
* `attribute_name` is the name of a metadata attribute.

The object itself will be stored under the key `object_name`.

As an example, the attribute `Type` of an object named `my_counter` will be accessed under the key `my_counter/Type` (assuming `separator`=`/`).

An additional attribute for each object can be maintained by the system, listing the names of all the `attribute_names` associated with the object (implemented as a set-CRDT).

Note: This design will restrict the keyspace visible to the user, as only part of the key will be used of the object name. Object names should not contain the character used as separator.

Option 2
-------
Couple each object with its metadata attributes as a single object:
Each object will be stored as a map-CRDT under the key `object_name`, containing both metadata attributes under map keys corresponding to the `attribute_names` and the data object under a special map key.

Option 3
-------
For each object there exists an additional metadata object containing all its metadata attributes:
Each object will be stored under the key `object_name`. Its metadata attributes will be stored as a map-CRDT under a key associated with the `object_name`, such as `object_name/md` or `_object_name`.

-----
Any of these designs can be implemented at the protocol buffer interface level. The interface would be extended with:
* Functions for reading and updating used-defined metadata attributes that will manipulate the key format and use regular `read_objects` and `update_objects` calls to read and write objects to Antidote.
* Special functions for reading and updating system metadata attributes (ex. access control) implementing additional mechanisms for enforcing required security invariants.

----
Note: In order to ensure that objects and their metadata attributes are mapped in the same server, the sharding mechanism can be modified to calculate shards based on a prefix of the key, omitting suffixes used for storing metadata attributes.
In that way, the objects `my_counter` and `my_counter/Type` will be mapped in the same server.

I propose implementing Option 3 and I can work on it.