Allow cleartext HTTP/2 (h2c) on JsonRpcAggregatorClient — inject OkHttpClient or select protocols

[MastaP]

Request

Let callers make JsonRpcAggregatorClient (and/or the underlying JsonRpcHttpTransport) talk to an aggregator over cleartext HTTP/2 (h2c, prior-knowledge) — not just HTTP/1.1.

Today (java-state-transition-sdk:1.4.2) the only constructors are:

JsonRpcAggregatorClient(String url)
JsonRpcAggregatorClient(String url, String apiKey)

JsonRpcHttpTransport builds its own okhttp client internally and there is no way to inject one or choose the protocol, so the client is effectively HTTP/1.1-only.

Why

Some deployments front aggregators with an HAProxy bind ... proto h2 frontend (cleartext HTTP/2 prior-knowledge). An HTTP/1.1 client gets java.io.IOException: unexpected end of stream against such a listener. Concretely, the Unicity subscription gateway proxies to upstreams over h2c (--upstream-h2c), but its startup shard-connectivity check used this SDK client and therefore crashed on boot against h2c upstreams. We had to bypass the SDK and hand-roll a Jetty h2c probe (HTTP2Client + setUseALPN(false)) just to call get_block_height over h2c. See aggregator-subscription issue #40 / PR #41.

okhttp already supports this via OkHttpClient.Builder().protocols(List.of(Protocol.H2_PRIOR_KNOWLEDGE)).

Suggested API (any one of these would solve it)

• A constructor / builder that accepts a pre-configured OkHttpClient (most flexible), or
• An option/flag to enable h2c prior-knowledge for http:// URLs (e.g. JsonRpcAggregatorClient(url, ClientOptions.h2cPriorKnowledge())), or
• Honor Protocol.H2_PRIOR_KNOWLEDGE when the scheme is http:// and an opt-in is set.

Benefit

Downstream consumers (e.g. the gateway) could use the SDK uniformly for both HTTP/1.1 and h2c upstreams and drop bespoke h2c probes, keeping request/response shapes (get_block_height, etc.) in one place.