RGB Stock CRDTs

[theacdutra]

Today the RGB module works based in unit of work concept, or that, each operation can be valid only when everything works, like transaction in database (commit and rollback operations). This approach is a way to prevent inconsistencies in stash.

However, This is not prevent stash inconsistencies in scenarios of the concurrent and/or parallel operations.

For example, Suppose we have a contract with intensive usage and by UX decisions, we allow the users to send and accept transactions Concurrently. One of both operations can be overring the state of the other, causing an inconsistent stash.

We could use a queue to prevent that, but this turns our infrastructure more centralized and also represents a single point of failure.

We can explore a way to turn Stash compatible with the CFDT approach (@cryptoquick's suggestion).

[cryptoquick]

I think CRDTs are the way. It would be great to use something like automerge.

[cryptoquick]

A CRDT solution based on automerge supersedes the solution in #258.