Now transparent and Cairo RMs have properly different keyspace paths.

…to artem/mempool-ro-tx

…tem/mempool-keyspace

…tem/mempool-keyspace

A cell is composed of two parts, it's details and a watermark.

For simplicity we only implement the write watermark, there was
originally a read watermark, however since that determined garbage
collection it was instead postponed until it can fit into the system
design.

The write watermark determines when values are final and reads can be
begin if they are not blocked by a pending write waiting to actually
write.

The details of the cell are quite simple, they just store onto the
value of the cell as well as any pending reads.

Co-authored-by: AHartNtkn <soobtoob@gmail.com>

Shards are a thin wrapper over their cells. Simply containg their ID
information and a mapping of keys to their cells.

For simplicity of use most deployment scenarios just see 1 cell per
shard, meaning that shards are a genserver wrapper over a more pure
cell. As we get more interesting process pressure the multi cell
nature of a shard may be more used

Co-authored-by: mariari <mariari@protonmail.ch>
Co-authored-by: agureev <artguril@proton.me>

This module serves as a supervisor the shards. We can start shards
like so:

Supervisor.start_shard(node_id, ["a"])

What is interesting is that they register themselves so we can look at
them like this:

Registry.via(node_id, Shard, :a)

However, they do it in a janky way but they are registered thankfully,
which is what future examples will be based on.

mariari: This module is messy, I have not properly refactored it, so a
lot is on the table to be done better. In particular it is not
hookedup to the replay nor rehydraytes the data from strorage, and
thus needs to be considered more properly

By intorudcing shards into the system a lot of work had to be
done. Namely in ordering which has to track the shards.

The integration isn't the cleanest as some questionable changes like:

@@ -528,9 +547,9 @@ defmodule Anoma.Node.Transaction.Mempool do

-    Storage.commit(node_id, round, writes)
+    Ordering.commit(node_id, round, writes, set_of_ids)

are done which seem incorrect and duplicate work that should really be
happening in Storage.

Further Replay integration is not properly had. We do not hydrate the
shards from storage and thus replay tests are currently disabled.

This should be correct immediately, but as a first integration this
should improve the codebase

Co-authored-by: mariari <mariari@protonmail.ch>

Shard examples, implemented rather striaght forwardly with a lot of
reuse, they are very nice examples to use, for example one can do this

iex(anoma@YU-NO)180> node_id = EShard.abc_val_a_unresve_advances_7_11
"example_262B3D6D6CFFEFDE5EA8C14D4A84B0E3"
iex(anoma@YU-NO)181> Registry.via(node_id, Shard, :a) |> :sys.get_state
%Anoma.Node.Transaction.Shard{
  cells: %{
    ["a"] => %Anoma.Node.Transaction.Shard.Cell{
      watermarks: %{write: 12},
      details: %{
        0 => %Anoma.Node.Transaction.Shard.Detail{
          cell: %{value: 5},
          pending: nil
        },
        3 => %Anoma.Node.Transaction.Shard.Detail{
          cell: %{value: 55},
          pending: nil
        },
        4 => %Anoma.Node.Transaction.Shard.Detail{cell: :empty, pending: nil},
        7 => %Anoma.Node.Transaction.Shard.Detail{
          cell: %{value: "Family Mart"},
          pending: nil
        },
        11 => %Anoma.Node.Transaction.Shard.Detail{cell: :empty, pending: nil},
        14 => %Anoma.Node.Transaction.Shard.Detail{cell: :empty, pending: nil}
      }
    }
  },
  node_id: "example_262B3D6D6CFFEFDE5EA8C14D4A84B0E3",
  id: :a
}

Makes debugging very easy.

The shard examples do not test the following:

1. rehydrating state from the database (the supervisor kicks back the
   children with default state if they do die).
2. multiple cells per shard. This should be trivially correct, but
   it's good to note.

Co-authored-by: AHartNtkn <soobtoob@gmail.com>