Tracking issues of migrating adapter based services

[Xuanwo]

As discussed in #5703:

I initially started building adapters like kv and typed_kv just for fun, exploring the potential of OpenDAL. These adapters were designed to be simple and primarily optimized for implementing services in an easy way.

However, over time, some users have begun using services built on kv and typed_kv more seriously, resulting in additional feature requests. For example, see #5701 and #5623.

Those factors combined made me wonder whether it's a good idea for us to keep both of those adapters. It seems we can simply retain KvReader and KvWriter, allowing services to use them directly instead of having to implement them each time. This also unlocks the potential for services to introduce more features without adding another layer of unnecessary abstraction.

Maybe we could migrate services to implement Access directly and reuse the components we already have. This would allow the community to implement great features, such as reading ranges from SQLite, more easily.

Let's start migrating adapter based services. This migration should not break any existsing services.

Tasks

• atomicserver
• cacache
• cloudflare_kv
• d1
• dashmap
• etcd
• foundationdb
• memcached
• memory
• mini_moka
• moka
• mongodb
• nebula_graph
• persy
• redb
• redis
• rocksdb
• sled
• sqlite
• surrealdb

[Xuanwo]

I will take redis first to as an example.

[JMLX42]

@Xuanwo if you do redis as an example, me and @jerome-caucat can do the sqlite one.

[JMLX42]

@Xuanwo any news on the redis implementation? We would love to be able to contribute the sqlite one ASAP.