Propagate server-side gRPC message-size limits to clients

[DevMattG]

Problem

mosaicod and its clients each reason about gRPC message size independently, and the two are not related today:

• Server (crates/mosaicod-core/src/params.rs) enforces max_grpc_message_size (default 50MB, clamped to [4MB, 128MB], configurable via MOSAICOD_MAX_GRPC_MESSAGE_SIZE) on tonic's max_decoding_message_size/max_encoding_message_size (mosaicod-grpc/src/server.rs). It also derives an internal target_message_size, used only for its own Arrow batch sizing.
• Client (Python SDK, comm/connection.py) hard-codes PYARROW_OUT_OF_RANGE_BYTES = 16MB and DEFAULT_MAX_BATCH_BYTES = 10MB as pre-send size checks. These numbers have no connection to whatever the server is actually configured with.

Consequence: if an operator raises MOSAICOD_MAX_GRPC_MESSAGE_SIZE to e.g. 128MB, clients still cap themselves at 16MB for no reason. If an operator lowers it below the client's assumed ceiling, the client's local check passes, but the server rejects the message with a decoding error instead of a clean client-side error.

Proposal

Expose the server's configured limits to clients via the existing do_action mechanism, rather than inventing a new negotiation channel. There's already a precedent for exactly this kind of server → client info exchange: the "version" action misc::version()), which the Python client calls during connection setup (_wait_for_available).

Concretely:

1. Add a new ActionRequest::Config variant ("config" tag) alongside version, returning max_grpc_message_size (and possibly target_message_size) from params::params().
2. Add a matching FlightAction.CONFIG + _DoActionResponse subclass in the Python SDK, following the same pattern as the other action responses.
3. Client calls this once at connection setup (same place as the existing version call), caches the result, and uses it — instead of the hard-coded constants — to decide when to flush/reject oversized batches.
4. Fall back to the current hard-coded constants if the server doesn't support the config action (older server version), so this isn't a breaking change in mixed-version deployments.

Alternatives considered

• Reject-and-report: rely on the server rejecting oversized messages and surfacing the real limit in the error status/details, and have the client adapt reactively. Simpler, but only self-corrects after a failed send — better as a defensive backstop than the primary mechanism.

Open questions

• Does the client need target_message_size at all, or is max_grpc_message_size sufficient (client derives its own flush threshold as a fraction of it)? Fewer fields to keep in sync either way.
• Should this be its own "config" action, or should max_grpc_message_size just be added to the existing version response instead of a new action?

[DevMattG]

Regarding the open questions:

• it would be good to pass target_message_size to the client anyway and let it decide whether to use it or not
• better to create a new info action that will incorporate both version and config sections in the same response