RFC-7740: Operator Composition

[Xuanwo]

I made some very important changes during the early stage of OpenDAL, especially the design of the current Access trait. Unfortunately, those design decisions based on wrong results because I was using an AMD Ryzen 9 5950X at the time, and it was affected by a bug I later discovered via https://xuanwo.io/2023/04-rust-std-fs-slower-than-python/. This means I overestimated the cost of the vtable and indirect calls.

However, when I found the bug, we had already moved too far forward. We had to keep going and had no way to turn back.

Now, thanks to all the AI tools, we have a chance to correct this design and build a new solid foundation for OpenDAL to move forward.

This new design will make OpenDAL more scalable, with no need to play with Rust type systems. It will also allow OpenDAL to build a stable ABI so that we can link to the same dynlib. Furthermore, it will allow languages like Python to split packages instead of bundling all services and layers into one.

OpenDAL is still new, let's rock!

---

Which issue does this PR close?

N/A.

Tracking issue: #7741.

Rationale for this change

OpenDAL's composition model has accumulated several structural problems that share one root:

• A static/dyn dual-trait world (Access + AccessDyn, five *Dyn op-body traits) bridged by TypeEraseLayer, while every Operator call already goes through Arc<dyn AccessDyn>.
• Two extension mechanisms with conflicting semantics: structural wrapping on the operation plane versus imperative mutation of the shared AccessorInfo for the HTTP client, executor, and capability. The imperative update_* API erases composition history, which produces real defects today: HttpClientLayer silently destroys HTTP instrumentation depending on layer order, op.clone().layer(...) leaks context mutations back into the original operator (the Java binding hits this path), double-applied layers have undefined context semantics, and set_native_capability can silently drop capability transforms.
• A fragmented vocabulary: service / backend / access / accessor name facets of the same thing.

This RFC proposes rebuilding the composition model in one shot: an object-safe Service trait (renaming Access), a hook-based object-safe Layer, an Operator that holds base providers plus a layer list and replays the composition on every mutation, and an explicit ServiceContext parameter on every operation method. All mutable shared state, the dual-trait machinery, OperatorBuilder, and finish() are deleted.

What changes are included in this PR?

A new RFC document core/core/src/docs/rfcs/7740_operator_composition.md, registered in the rustdoc RFC index.

Are there any user-facing changes?

None in this PR itself. The proposed design is a major breaking change to the raw API; the impact and migration story are detailed in the RFC's Drawbacks and "No compatibility logic" sections.

AI Usage Statement

This RFC was drafted with Claude Code (claude-fable-5) under the author's direction; the design and all decisions in it are the author's.