wasi-keyvalue: add optional redb persistent backend

[cargopete]

Summary

Adds a persistent redb-backed storage backend to `wasmtime-wasi-keyvalue`, behind an optional `redb` Cargo feature. The existing in-memory backend is completely unchanged.

Related discussion: posted in the `#wasi` channel on the Bytecode Alliance Zulip (bytecodealliance.zulipchat.com) — topic: wasi-keyvalue redb backend (approach question).

Standalone reference implementation: https://github.com/cargopete/wasmtime-wasi-keyvalue-redb

Design

• New `redb` feature gate — zero cost when not enabled
• `Bucket` becomes an enum: `InMemory(HashMap<...>)` | `Redb(String)`
• `WasiKeyValueCtxBuilder::redb_file(path)` configures the database
• Identifiers: `"redb"` → default bucket, `"redb:"` → named bucket
• All buckets share one database file; keys encoded as `{bucket}\0{key}`
• Full `store` + `atomics` + `batch` interface coverage

Usage

```rust
let ctx = WasiKeyValueCtxBuilder::new()
.redb_file("/var/lib/my-component/kv.redb")?
.build();
```

Then `open("redb")` or `open("redb:mybucket")` from the component.

Notes

Opening this as a draft since I've posted in `#wasi` on Zulip asking whether the preferred approach is an in-crate feature (this PR) or a separate published crate. Happy to go either direction — wanted to show concrete code either way.

I'm also aware redb doesn't satisfy the Phase 2 portability criteria directly (those require Redis/DynamoDB etc.). A Redis backend is next on my list — just wanted to validate the host trait shape first with a dependency-free embedded store.

[cargopete]

One more CI note: cargo vet is flagging redb 4.1.0 as unvetted (no existing audit in any of wasmtime's trusted sources — Embark, Google, Mozilla, Spin). A cargo vet certify redb 4.1.0 safe-to-deploy audit would be needed before this could merge, which is ~29k lines of redb source.

This feels like relevant signal for the architecture question I raised on Zulip: if the backend lives in a separate published crate (as in the standalone repo), wasmtime itself never takes on the redb audit burden — only users who explicitly depend on the external crate do. Happy to keep this as an in-tree feature if that's preferred, but wanted to flag the vet cost explicitly.

[pchickey]

Thank you for flagging the vetting issue. Yes, because accepting this crate into the wasmtime tree would require us (the Wasmtime maintainer team) to vet it, and we do not have the capacity to vet a 29kloc dependency, my opinion is that this crate should not land in Wasmtime. Your maintaining the crate elsewhere is, of course, welcome.

In general the long term solution that the Wasmtime team hopes for to solve this vetting problem is, in the wasip3 era we are hopefully entering soon, virtualization will finally work properly for implementations of the keyvalue interface to be made purely as a webassembly component that imports http, sockets or the filesystem.

[cargopete]

Thanks @pchickey — that's exactly the clarity I was looking for, and the WASIp3 virtualization point is a good north star to keep in mind.

The standalone crate is already published at https://github.com/cargopete/wasmtime-wasi-keyvalue-redb for anyone who needs an embedded persistent backend in the meantime. I'll follow the same pattern for a Redis backend.

[cargopete]

Follow-up: the Redis backend is now also available as a standalone crate — https://github.com/cargopete/wasmtime-wasi-keyvalue-redis — which is the one that actually satisfies the Phase 2 portability criteria (Redis is explicitly listed). Same pattern, 6/6 tests passing against a live Redis instance.