fix(services/etcd): make the gRPC decoding size limit configurable

[SatyamPandey-07]

Which issue does this PR close?

Closes #8164.

Rationale for this change

services/etcd can write a value larger than 4 MiB when the etcd server
allows it (the fixture configures --max-request-bytes=10485760), but reading
that value back fails:

decoded message length too large: found 8388766 bytes, the limit is: 4194304 bytes

etcd-client 0.19.0 applies its own 4 MiB gRPC decoding limit to KV
responses, independently of anything the etcd server allows. This is a
client-side response-size limit, so Capability::write_total_max_size cannot
describe it, and until now services/etcd gave no way to configure it.

What changes are included in this PR?

• core/services/etcd/src/config.rs: add EtcdConfig::max_decoding_message_size: Option<usize>, plus a unit test that it round-trips through from_iter
  (so it can be set via OPENDAL_ETCD_MAX_DECODING_MESSAGE_SIZE in the
  behavior test harness and via URI options).
• core/services/etcd/src/backend.rs: add the matching
  EtcdBuilder::max_decoding_message_size(limit: usize) setter and thread the
  value into EtcdCore::new.
• core/services/etcd/src/core.rs: EtcdCore now carries the configured
  limit and applies it to KvClient before issuing a get
  (client.kv_client().max_decoding_message_size(limit)), instead of using
  the pooled Client's default-limited get. When unset, behavior is
  unchanged (etcd-client's own 4 MiB default applies) — this does not default
  to an unbounded response size.
• .github/services/etcd/{etcd,etcd-cluster,etcd-tls}/action.yml: set
  OPENDAL_ETCD_MAX_DECODING_MESSAGE_SIZE=10485760 in all three CI fixtures,
  matching the --max-request-bytes=10485760 already configured on the etcd
  server side in fixtures/etcd/*.yml, so the existing 8 MiB
  ReadBehavior_LargePayload_RoundTripsExactly(Async) .NET behavior tests can
  pass against etcd.
• bindings/dotnet/OpenDAL/ServiceConfig/EtcdServiceConfig.cs,
  bindings/java/src/main/java/org/apache/opendal/ServiceConfig.java,
  website/data/services.json: regenerated to add the new
  max_decoding_message_size field to the generated per-language config
  classes and the docs data.

I did not find an existing "temporary etcd-specific skip" on the large-payload
behavior test on main (checked
bindings/dotnet/OpenDAL.Tests/Behavior/ReadBehaviorTest.cs, the CI matrix
planner at .github/scripts/test_behavior/plan.py, and the dotnet binding
exclude list), so there was nothing to remove for that part of the issue's
acceptance criteria.

Are there any user-facing changes?

Yes: Etcd now accepts an optional max_decoding_message_size config
option/builder method. It's additive and opt-in — existing configurations
keep etcd-client's current 4 MiB read limit unless they explicitly raise it.

AI Usage Statement

AI materially assisted in writing this PR's code and description. I did not
have a Rust toolchain available to run cargo build/test/clippy or the
odev config generator locally, so the generated file updates
(EtcdServiceConfig.cs, ServiceConfig.java, website/data/services.json)
were reproduced by hand against the generator's templates and verified
against this repo's own CI output rather than a local run.

[erickguan]

Are there practical downsides of using larger decoding size?
How does a typical etcd server respond differently with a larger response payload?
How does an etcd client allocate differently with a larger response size?

[SatyamPandey-07]

Thanks for the review @erickguan! Here is a breakdown of how the decoding size limit affects the client, server, and overall memory footprint:

1. Are there practical downsides of using a larger decoding size?

• Memory usage & OOM risk: The 4 MiB gRPC default in tonic/prost/etcd-client is a protective ceiling against malicious responses or unexpected payload spikes causing high memory allocations. Raising this limit allows larger payloads to be decoded into memory, increasing peak heap usage per read request.
• etcd cluster performance: etcd is designed as a strongly consistent coordination/metadata store (via Raft). Reading/writing large payloads can increase network latency, cause head-of-line blocking on gRPC HTTP/2 streams, and put memory pressure on the etcd server.
• Safety in OpenDAL: Because of these trade-offs, this PR keeps the option strictly opt-in. The default remains None (which preserves etcd-client's 4 MiB default). Users only raise this limit when they have deliberately configured etcd (e.g. via --max-request-bytes) to store larger entries.

---

2. How does a typical etcd server respond differently with a larger response payload?

• Server limit vs. Client limit: The etcd server enforces --max-request-bytes (default 1.5 MiB in upstream etcd). If an etcd server is started with a higher limit (e.g., --max-request-bytes=10485760 as in our CI fixture), the server successfully accepts and stores writes up to that size.
• Response handling: When fulfilling a get/RangeRequest, the etcd server serializes and streams the entire protobuf RangeResponse over gRPC. The server does not automatically split or paginate single-key reads.
• Where the failure occurs: The server transmits the response normally; the failure happens on the client side during gRPC decoding when tonic inspects the response frame header and finds the length exceeds its 4 MiB ceiling (decoded message length too large).

---

3. How does an etcd client allocate differently with a larger response size?

• Dynamic allocation (no static pre-allocation): tonic and prost do not allocate the configured maximum limit up front. max_decoding_message_size is strictly an upper-bound check against the length header before decoding.
• Allocation path on receive:
  1. tonic reads the incoming gRPC frame into contiguous memory (BytesMut/Bytes).
  2. prost decodes the protobuf bytes into heap-allocated Rust types (RangeResponse, KeyValue, and Vec<u8> value fields).
  3. OpenDAL converts this into Buffer::from(kv.value().to_vec()).
• Impact of raising the limit: Memory allocation scales linearly with the actual size of the incoming message. Raising the limit allows the client to allocate and deserialize responses up to the new threshold instead of aborting at 4 MiB.

[Xuanwo]

closed for no human in the loop.

[SatyamPandey-07]

Hi @Xuanwo thanks for the clarification. I noticed PR #8193 was closed for “no human in the loop.” I had responded to @erickguan questions and also updated the branch with the latest main. If the approach still looks useful, should I reopen the PR or submit a new one for review?

[Xuanwo]

Hi @Xuanwo thanks for the clarification. I noticed PR #8193 was closed for “no human in the loop.” I had responded to @erickguan questions and also updated the branch with the latest main. If the approach still looks useful, should I reopen the PR or submit a new one for review?

If you are the human, yes. If you are the agent or simply the meat proxy for agent, no.