Add TransportConfig to control low level transport settings

[idelpivnitskiy]

Motivation:

Users need a way to change low-level Netty settings, like AdaptiveRecvByteBufAllocator parameters. In the future, we can use this interface for more similar settings without the need to change client/server builder.

Modifications:

• Add TransportConfig and TransportConfigBuilder in transport-api module;
• Add methods on SingleAddressHttpClientBuilder and HttpServerBuilder to let users pass TransportConfig;
• Wire it up to propagate to Tcp[Client|Server]ChannelInitializer as TransportConfigInitializer;

Result:

Users can control AdaptiveRecvByteBufAllocator settings.

[idelpivnitskiy]

This config follows the patters of [Client|Server]SslConfig, ProxyConfig, RedirectConfig, and [H1|H2]ProtocolConfig by having an interface and a builder.

[daschl]

The interface as it stands currently assumes that all the options are supported by the implementing one. Of course just having netty they are naturally supported, but I wonder if we should start to document/devise a strategy if there is a transport in the future which does not support a specific option? i.e. maxReadAttemptsPerSelect assumes a non-blocking style eventloop with a selector

[idelpivnitskiy]

For ServiceTalk API I would consider it as highly unlikely scenario that we ever change transport implementation. If we do, it will worth the major version bump and then we can also deprecate options and move them on impl-specific variants. During the transition period, it will be fine if the new impl ignores these options and logs about it or throws an exception.

[daschl]

So combined with the above it would be maxReadPerSelect times maxBytesPerRead ?

[idelpivnitskiy]

Yes, that will be the upper bound. The receive allocator may decide to lower the bound, then it might be smaller.

[daschl]

The interface as it stands currently assumes that all the options are supported by the implementing one. Of course just having netty they are naturally supported, but I wonder if we should start to document/devise a strategy if there is a transport in the future which does not support a specific option? i.e. maxReadAttemptsPerSelect assumes a non-blocking style eventloop with a selector

[bryce-anderson]

This look correct to me but I share in @daschl's concern that this is highly specific to netty and potentially a foot-gun for users. Is there a chance we could simply set a better default, or does this need to be user configurable?

[idelpivnitskiy]

Is there a chance we could simply set a better default, or does this need to be user configurable?

The current defaults that we have are considered to be the best for a typical workflow. However, there are specific users that receive heavy payloads. Those need to tune these values to read data more aggressively to maximize efficiency.