Parameters of SETTINGS frame are not configurable and does not match h2 server SETTINGS frame

[serputko]

While debugging http2 plugin I found that parameters of SETTINGS frame are different for chrome, jmeter and server and there is no ability to configure them. At the same time it looks like current implementation is not using SETTINGS frame at all despite it's core configuration concept of http2.

Example of SETTINGS frame values(got from Charles proxy):
Browser(chrome)
SETTINGS_HEADER_TABLE_SIZE = 65536
SETTINGS_ENABLE_PUSH = 0
SETTINGS_MAX_CONCURRENT_STREAMS = 1000
SETTINGS_INITIAL_WINDOW_SIZE = 6291456
SETTINGS_MAX_FRAME_SIZE = 16384
SETTINGS_MAX_HEADER_LIST_SIZE = 262144
Jmeter
SETTINGS_HEADER_TABLE_SIZE = 4096
SETTINGS_ENABLE_PUSH = 1
SETTINGS_MAX_CONCURRENT_STREAMS = 32
SETTINGS_INITIAL_WINDOW_SIZE = 8388608
SETTINGS_MAX_FRAME_SIZE = 16384
SETTINGS_MAX_HEADER_LIST_SIZE = unlimited
Server
SETTINGS_HEADER_TABLE_SIZE = 4096
SETTINGS_ENABLE_PUSH = 1
SETTINGS_MAX_CONCURRENT_STREAMS = 128
SETTINGS_INITIAL_WINDOW_SIZE = 65536
SETTINGS_MAX_FRAME_SIZE = 16777215
SETTINGS_MAX_HEADER_LIST_SIZE = unlimited

As per specification:

The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.
SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer. Different values for the same parameter can be advertised by each peer. For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources.

I suppose http2 plugin should refer to SETTINGS frame values in scope of client-server interaction rather then using jetty client settings. For example: use SETTINGS_MAX_CONCURRENT_STREAMS value instead of httpJettyClient.maxThreads to handle multiplexing inside 1 tcp connection. So we need to have ability to set SETTINGS frame values somewhere.

Also when setting SETTINGS_MAX_CONCURRENT_STREAMS = 400, we should not expect requests be processed with 400 concurrent streams, as server might have SETTINGS_MAX_CONCURRENT_STREAMS=256, which means server is limiting concurrency on it's side

Thanks

Originally posted by @serputko in #39 (comment)