Design of ALPN contexts and L4 engine

[gcm3651]

What happened?

create a client & server engine in one program with different h3 callbacks, xqc can't send request any more。
i think it's becase the h3 cbs is saved in a global variable h3_ctx，when diffent engine register different h3 cbs, previous registered cbs would be overwritten, xqc_h3_ctx_get_app_callbacks would only can get the last registered cbs。

i tried to save cbs in engine, and this problem don't produce any more.
just like this

but i'm not sure if it is good method to fix this issue.

Steps To Reproduce

create client engine firt, then create sever engine in one program, this use this client engine send request, request can't send any more.

Relevant log output

No response

[Kulsk]

if you need multiple definitions of h3 callback functions and bound them to engine, this is the most simple way to solve the problem. but it is still not a solution good enough to solve the management problem between ALPN layer and Transport layer.

This problem dues to the history of xquic's design:
About half a year ago, xquic almost got the same solution, binding L7 ALPN layer with L4 Transport Layer, making it inflexible to extend new L7 protocols on the L4 Transport Layer.
Then, xquic split L7 protocols from the L4 Transport protocol with the design of ALPN registration mechanism, making it extendable to add new L7 protocols without modifying L4 Transport codes, while reuse the L4 contexts and callback functions even between different L7 protocols based on the L4 Transport protocol.
In order to compat with the original http3 interfaces, h3_ctx is designed to be a singleton, while application layer need to differ the detailed operations among the callback.

What's more, engine is not strongly related to h3_ctx, applications can define as much h3_ctx as it wants while sharing the same engine, which means they are not being a 1-to-1 relationship.

A reasonable way to solve this problem is to attach engine to h3_ctx, with a N-to-N rule, remembering the different h3 config while reusing the engine if it is need. means the h3_ctx will be some engine-like module in xquic's http3 implementation, which will influences a lot of interfaces and invokes lots of job.

[Kulsk]

I will convert this issue to discussion, maybe we can work out a better idea