Read/write set encoding and transport

[kostko]

A serializable structure for storing read/write sets should be defined and used to transport the per-transaction read/write sets:

• From the clients to the transaction scheduler (optionally with support for signing by the pre-executor).
• From the transaction scheduler to compute nodes.
• From compute nodes to runtimes running on the compute nodes.

The structure should support key coarsening (by prefix).

[kostko]

Initial proposal for encoding is something simple like:

// CoarsenedKey is a coarsened key prefix that represents any key that
// starts with this prefix.
type CoarsenedKey []byte

// ReadWriteSet is a read/write set.
type ReadWriteSet struct {
    // Granularity is the size of the key prefixes (in bytes) used for
    // coarsening the keys.
    Granularity uint16
    // ReadSet is the read set.
    ReadSet []CoarsenedKey `codec:"read_set"`
    // WriteSet is the write set.
    WriteSet []CoarsenedKey `codec:"write_set"`
}

As mentioned by @bennetyee in https://github.com/oasislabs/private-rfcs/pull/140#discussion_r298449202 if this is too large we can trade some space for false positives by using a bloom filter, but I guess that at the initial granularity (account addresses) this will not be a problem.

[bennetyee]

This lgtm. One potential minor issue is that this means that coarsening has to be uniform for the contract. We may eventually want to allow applications to specify (based on prefixes) regions with different degrees of coarsening; this is likely to be useful if/when we have libraries where they may be optimized for good locality using different degrees of coarsening. It would make the representation -- and the algorithms -- more complex, since we would be pushing Granularity into CoarsenedKey.