feat: Http2ClientProtocolConfig and GrpcClientProtocolConfig in internal proto

[derektriley]

Description:
This pull request introduces support for per-node protocol configuration for block node connections, allowing each node to specify custom HTTP/2 and gRPC client protocol settings. These changes make the configuration of block node connections more flexible and robust, enabling fine-tuned control over connection behavior for each node. The implementation includes updates to protobuf definitions, Java classes, and build configurations to support and process these new settings.

Protocol configuration support for block node connections

• Updated the protobuf schema (block_node_connections.proto) to add optional Http2ClientProtocolConfig and GrpcClientProtocolConfig messages, and corresponding fields to BlockNodeConfig, enabling per-node protocol configuration.

Java implementation for protocol config extraction and usage

• Enhanced BlockNodeConnectionManager to extract and store optional HTTP/2 and gRPC protocol configs from configuration files, and provide accessors for these configs.
• Modified BlockNodeConnection to use the extracted protocol configs when creating the WebClient pipeline, combining available protocol configs for each node connection.

Build and module configuration updates

• Added dependencies for Helidon HTTP/2 and gRPC webclient modules in build.gradle.kts and module-info.java to support protocol config features.

Testing and cleanup

• Updated test code to use new BlockNodeConfig constructors with protocol config arguments, ensuring compatibility with new config structure.
• Ensured protocol config maps are cleared during manager metadata cleanup to prevent stale config usage.

Related issue(s):

Fixes #21777

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[lfdt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codecov]

Codecov Report

❌ Patch coverage is 74.03846% with 27 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...cks/impl/streaming/BlockNodeConnectionManager.java	60.29%	12 Missing and 15 partials ⚠️

@@             Coverage Diff              @@
##               main   #21785      +/-   ##
============================================
+ Coverage     71.82%   71.84%   +0.02%     
- Complexity    24546    24578      +32     
============================================
  Files          2670     2674       +4     
  Lines        103892   104026     +134     
  Branches      10867    10890      +23     
============================================
+ Hits          74619    74739     +120     
- Misses        25231    25233       +2     
- Partials       4042     4054      +12     

Files with missing lines	Coverage Δ	Complexity Δ
...app/blocks/impl/streaming/BlockNodeConnection.java	86.82% <100.00%> (+0.82%)	75.00 <0.00> (+4.00)
...blocks/impl/streaming/BlockNodeProtocolConfig.java	100.00% <100.00%> (ø)	1.00 <1.00> (?)
...cks/impl/streaming/BlockNodeConnectionManager.java	76.45% <60.29%> (-2.71%)	65.00 <5.00> (+5.00)	⬇️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.02% (target: -1.00%)	✅ 88.46%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (df0b448)	103797	78616	75.74%
Head commit (938f016)	103894 (+97)	78711 (+95)	75.76% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#21785)	104	92	88.46%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

[timfn-hg]

Can we not just include the Http2ClientProtocolConfig and GrpcClientProtocolConfig configs on the BlockNodeConfig object, or maybe some wrapper that encapsulates all three configs, instead of having three different collections with the different configs?

[derektriley]

We could, however I wanted to build the io.helidon.webclient.http2/grpc variants just once when parsing the json, rather than building it everytime we open a new connection

[timfn-hg]

That's fine, but I still think it would be a lot cleaner to keep them configs in one single object that we can pass around instead of needing to use additional maps/getters that need to be called by the connection objects to get the remaining configs.

[timfn-hg]

What do you think about doing something like this:

record BlockNodeConnectionConfig(BlockNodeConfig nodeConfig, Http2ClientProtocolConfig http2Config, GrpcClientProtocolConfig grpcConfig, int maxMessageSizeBytes) { }

This way we have everything in one config object for each connection, and then instead of passing in BlockNodeConfig into the connection's constructor, we could pass in the full BlockNodeConnectionConfig record which would contain everything the connection needs. This would also remove the need to have BlockNodeConnectionManager#getBlockNodeProtocolConfigs since the configs are passed in at construction time. You could also set the default max message size as you are parsing the config if you see its not set in the config file, that way we don't need to worry about a bunch of if/else statements that are being executed when the connection task is being created.