track and use additional h2 settings for UA emulation and reporting

[GlenDC]

• initial_stream_window_size
• initial_stream_id
• initial_connection_window_size
• max_concurrent_streams
• max_frame_size
• max_header_list_size
• header_table_size
• headers_priority
• settings_order
• priority

1. support in h2 proto
   • expose for incoming h2 conn; During handshake or for each request?
   • respect these settings for client conn to use them
2. add them also to rama-ua
3. report these in rama-echo and rama-fp
4. also ensure they are emulated

[GlenDC]

Using network sniffers or public tooling such as https://browserleaks.com/http2 you can see these settings easily:

• initial_stream_window_size: SETTINGS_INITIAL_WINDOW_SIZE
• initial_stream_id: Stream ID
• initial_connection_window_size: ???
• max_concurrent_streams: SETTINGS_MAX_CONCURRENT_STREAMS
• max_frame_size: SETTINGS_MAX_FRAME_SIZE
• max_header_list_size: SETTINGS_MAX_HEADER_LIST_SIZE
• header_table_size: SETTINGS_HEADER_TABLE_SIZE
• headers_priority: ???
• settings_order: order the settings are defined in
• priority: PRIORITY (flag???)
• something else???

More info also: https://lwthiker.com/networks/2022/06/17/http2-fingerprinting.html#the-settings-frame

As these setting order is also important it might be best to internally store it like a Vec<H2Setting> vec of enums so that you know the orders. Similar to how pseudo header order also stores the pseudo headers as a vec-like internally.

[GlenDC]

Have a look at https://docs.rs/rama/latest/rama/http/proto/h2/struct.PseudoHeaderOrder.html as that is for sure what you can mimic.

By the way even if you store it internally as a vec, doesn'nt mean you need to do it via a push mechanism, you can still do it with setters / builder pattern, and just store them internally as a vec to preserve order anyway. The public api doesn't have to define the private API. So feel free to use your creative freedom here.