Distributed trasaction in kvdb - prepare trasaction [1/n]

Summary:
Diff 1/n for implementing distributed transactions in `kvdb`.

This diff implements prepare transaction function in `kvdb_storage` layer.

In the prepare phase of the transaction
1. Form `read_locks` and `write_locks` depending on which rows are read or mutated
2. lock the version of the affected rows
3. insert transaction manifest in the `transaction_manifest` column family
4. insert transaction record in the `transaction_ledger` column family

Example insertions during prepare transaction call...
```
                                                        │
                                                        │
                                                        │
                                                    prepare
                                                   transaction
                                                        │
                                                        │
                           ┌───────────────────┬────────┴───────────┬────────────────┐
                           │                   │                    │                │
                           │                   │                    │                │
┌────────┬─────────┬───────┼───────┐   ┌───────┼────────┐  ┌────────┼──────┬─────────┼──────┐
│  data  │  ttl    │internal_meta  │   │   entity_meta  │  │  transaction  │  transaction   │
│        │         │       │       │   │       │        │  │   manifest    │    ledger      │
┼────────┼─────────┼───────┼───────┤   ┼───────┼────────┼  ┼────────┼──────┼─────────┼──────┼
│        │         │       │       │   │       │        │  │        │      │         │      │
│        │         │       │       │   │       │        │  │        │      │         │      │
│        │         │       │       │   │       │        │  │        ▼      │         ▼      │
┼────────┼─────────┼───────▼───────┤   │       ▼        │  │ {put, ...,    │{status=pending,│
│        │         │{lock, version}│   │{lock, version} │  │  delete,...   │participants=..,│
┼────────┼─────────┼───────────────┤   │                │  │  ....}        │leader=..,..}   │
│        │         │               │   │                │  │               │                │
│        │         │               │   │                │  │               │                │
│        │         │               │   │                │  │               │                │
└────────┴─────────┴───────────────┘   └────────────────┘  └───────────────┴────────────────┘
```

**Locks optimizations and interleaving with other transactions/requests**
If there is a transaction that has a read lock on an entity and another request had read the same entity before it (hence didn't have the lock in its version), the earlier request should succeed. See case #1 and #2 in the doc https://fburl.com/gdoc/5bpqm79c.

This mean txn version check needs to
- Make sure the mismatch is not due to ver mismatch but rather due to a lock in it. This additional check can happen only on version mismatch
- Further optimization 1) store version separately 2) store version as a fixed bits 3) version check the list in its entirety or should we compare one version by one version
- Add a marker to indicate ongoing transaction on an entity, maybe at tab,key level. We can check for existence of this marker before doing additional version checks.

Reviewed By: jaher

Differential Revision:
D78693890

Privacy Context Container: L1209723

fbshipit-source-id: 6d03b0104bd376b2864bb36fa2c40988f910baea

Author: Ruchir Amin

src/wa_raft_label.erl

@@ -8,7 +8,7 @@
 -module(wa_raft_label).
 -compile(warn_missing_spec_all).
 
--type label() :: dynamic().
+    -type label() :: dynamic().
 
 -export_type([label/0]).