some random thought on add RMW

[ming535]

I think it's useful to support RMW (Read Modify Write) for test purpose.
The API could look like this:

    pub async fn rmw(&self, key: &[u8], lsn: u64, value: &[u8], f: fn(&[u8], Option<&[u8]>) -> Option<[u8]>) -> Result<()>;

The f is a function that takes the old key value and returns the new value. rmw will set the new value for this key+lsn.

The purpose of this API is mainly for testing the "Atomicity" of the tree operation.
We can enable it under special feature flag/test mode.

To test the "Atomicity" of concurrent tree operation, we can devise a client using this API.

For example, we can have concurrent written the tree with the "value" layout/encoded like this (using the same key and lsn).

    last_written_thread_id,[thread_id:checksum],[thread_id:checksum]..., [thead_id,checksum]

Each thread rmw to the same "key" and modifies different part ("thread_id:checksum") of the "value".

The f for each thread:

1. calculates the checksum of the whole "value" put it into its own slot ([thread_id:checksum])
2. and change the "last_written_thread_id" to itself.

Another thread read this "key":

1. use the "last_written_thread_id" to find the "thread_id:checksum"
2. calculate the checksum checker_checksum using the same f
3. verify if the checker_checksum is the same as the checksum in "thread_id:checksum".

We can also add some random garbage into the "value" make the page more likely to split (The current implementation seems to split a page on the size of the page rather the number of entries in the page).

[huachaohuang]

Sounds good to me. Users may also need this API, but we can start with tests.