* Update proto to send `max_frame_no` while inserting frames
We plan to allow multiple (non concurrent) writers. If a transaction's
`max_frame_no` does not match the server's `max_frame_no`, then it
has missed some new writes and we can abort the transaction
* Updates storage trait's insert_frames definition
- Change parameter type `FrameData` to `Frame` from rpc def, to
avoid unnecessary copying
- Take `max_frame_no` param
* Use `insert_frames` method
* cleanup: remove `insert_frame` method and impl
* Remove `FrameData`, use `Frame` from proto instead
* Add storage server RPC client
* Address review comments
- Use `#[tracing::instrument]` wherever appropriate
- Remove `Mutex` for `client` and `clone` it wherever required
- Avoid reading env variable inside the lib, rather take a config object
- Make the private methods of `DurableWal` async
- Don't try to create a runtime, instead assume it always exists. Let the caller create it
- Update proto:
- remove `max_frame_no` from `InsertFramesRequest`
- make `page_no` to `u32` in the proto
- Update storage server to have `page_no` as `u32`
* Add build and version files
* Add `FrameStore` trait
This trait provides the methods which can be implemented by different
storage backends like Redis, Foundation DB etc.
* Add a gRPC server which implements Storage Server proto
* Add storage server runner with pluggable storage backends
* Add an InMemory FrameStore
* Address review comments
- Remove unnecessary Arc/Mutex in the Service struct
- Chnage all `&self mut` to `&self` in the `FrameStore` trait, handle
locking internally
* Set cargo publish to false