RFC-7130: Route Layer

[Xuanwo]

Which issue does this PR close?

None

Rationale for this change

Add RouteLayer so that users can route requests based on path.

What changes are included in this PR?

We gonna build something to allow users to:

fn build_default() -> Result<Operator> {
    Operator::new(services::Memory::default())?.finish()
}

fn build_parquet_fast_path() -> Result<Operator> {
    Operator::new(services::Memory::default())?
        .layer(TimeoutLayer::default().with_timeout(Duration::from_secs(3)))
        .finish()
}

fn build_routed_operator() -> Result<Operator> {
    let default_op = build_default()?;
    let parquet_op = build_parquet_fast_path()?;

    let routed = default_op.layer(
        RouteLayer::builder()
            .route("**/*.parquet", parquet_op)
            .build()?,
    );

    Ok(routed)
}

Are there any user-facing changes?

AI Usage Statement

Parts of this PR were drafted with assistance from Codex (with gpt-5.2) and fully reviewed and edited by me. I take full responsibility for all changes.

[MrCroxx]

LGTM！This is a very good feature.

There’s one thing I’m not quite sure about: when specifying the purpose of a route in the fn route() method, is it better to use an Operator or an Accessor? Although the boundary between the two doesn’t seem very strict at the moment, using an Accessor might allow for more complex composition rules?

[Xuanwo]

LGTM！This is a very good feature.

There’s one thing I’m not quite sure about: when specifying the purpose of a route in the fn route() method, is it better to use an Operator or an Accessor?

My current plan is to use Operator, as it is part of our stable public API. I also prefer to avoid letting users interact directly with Accessor.

Although the boundary between the two doesn’t seem very strict at the moment, using an Accessor might allow for more complex composition rules?

Ideally, the Operator is simply a wrapper around the Accessor. If users need to perform more complex operations, they can directly construct the Accessor and use Operator::new.

[flaneur2020]

LGTM! lookin really nice

[koushiro]

LGTM

[meteorgan]

LGTM. It's an interesting idea.