feat(rio): rio_v2 is compatible with minio for storing data. (#3115)

* Set up a compatibility layer for replacing old Rio components with new ones.

* fix(rio). compress range

* feat(rio). Add the experimental feature rio_v2 to support minio data at the binary level.

* feat(rio_v2): add sse-c test

* test compression component

* simple fix

* fix minlz encode

* fix metadata

* fix kms key cache error

* Update launch.json

* ci: set nix crate download user agent

* fix: gate obs pyroscope backend

* ignore minio test

* fix encrypt check

* fix

* fix

* fix

* Update object_usecase.rs

* Update ci.yml

* fix

* ci add rio-v2 test

* fix

* ci fix

* fix

* Reconstructed into a more reasonable compatibility mode

* fix

* fix

---------

Signed-off-by: houseme <housemecn@gmail.com>
Signed-off-by: 唐小鸭 <tangtang1251@qq.com>
Co-authored-by: houseme <housemecn@gmail.com>
Co-authored-by: cxymds <Cxymds@qq.com>
Co-authored-by: 安正超 <anzhengchao@gmail.com>

crates/kms/src/lib.rs

@@ -33,6 +33,14 @@
 //! - **Data Encryption Keys (DEK)**: Generated per object, encrypted by master keys
 //! - **Object Data**: Encrypted using DEKs with AES-256-GCM or ChaCha20-Poly1305
 //!
+//! ## Caching Discipline
+//!
+//! KMS may cache stable master-key metadata, but it must not cache or reuse generated
+//! data encryption keys by master key id alone. A generated DEK and its encrypted
+//! ciphertext can be bound to the object encryption context, such as the bucket and
+//! object path. Reusing it for another object can break context validation and would
+//! also violate the expected per-object DEK model for SSE-S3 and SSE-KMS.
+//!
 //! ## Example
 //!
 //! ```rust,no_run