TiKV storage backend

[poelzi]

Description

Failures of larger nodes (200 TB+) will result in long recovery times and traffic.
Instead of writing to a local rocksdb, a tikv backend could be implemented, which maps the easiest to the current rocksdb storage backend.
A cluster of smaller tikv nodes, using zfs or bcachefs with ssd + hdds provide the storage and a frontend walrus node provides the walrus api.

• Recovery of a node stays within the cluster
• No stake is slashed when a node fails
• Frontend nodes could run stateless, making fallback and scaling easy
• TiKV coprocessor could allow interesting optimizations

In a later stage, multiple frontends for one storage cluster could be supported, making walrus distribute read/write operations on the frontends without loadbalancer.

Code of Conduct

• I agree to follow this project's Code of Conduct.

[github-actions]

Thank you for opening this issue, a team member will review it shortly. Until then, please do not interact with any users that claim to be from Sui or Walrus support and do not click on any links!