shared-state multi writer mode proposal

[spiccinini]

Currently shared-state can't store information in a way that multiple nodes can modify all its keys (multi-writer).
This is because the author of a key is re-publishing it with the biggest TTL all the time, not leaving space for others to modify the value of that key. It was though for a one writer per key scheme.

The proposal is to add a multi-writer mode that can also persist the information so that it survives reboots of the full network (for example due to a big power loss in the region).

There are a lot of use cases, for example: List network nodes service #867

The following are considered as premises:

• Each key is created only by one node "at a time". So for example there is not a "mynetwork" key in the database that all the nodes create on first boot. The typical key may be the name of the the hostname that adds information of itself but other schemes are intended to be suported, for example storing information with uuids like vouchers, notifications, etc.
• The information stored does not vary often (for example, firmware versions may be stored but not current signal levels)

Proposal:

• Provide the comand shared-state-multiwriter to access this mode/part of the database
• Use a permanent storage by default (maybe selectable to temporary in the future if we find an use case for that)
• Use an ordered way of modifying the value of a key so that it can be merged "monotonically". The simplest scheme is to use a timestamp (the last timestamp wins in the merge). Another scheme is to use a counter and a random string nounce. For example the key starts at with counter: 1, nonce: "s6qgHkMT", and then other node changes it to counter: 2, nonce: "mEVfaCb7". If the counters are equal the lexicographic order is used is used to select the winner for the merge:

if local.counter == other.counter: 
    return local if local.nonce > other.nonce else other