Start Http3

[SentryMan]

initial draft of Http3.

part of #46

relies on ptrd/flupke#18 and ptrd/flupke#17

[SentryMan]

@mechite what do you think of this so far

[mechite]

I think "yes". Great simple WebTransport implementation that won't bother
anyone, and HTTP3 done perfectly.

Random thought — do you think we could perhaps bump the source version
down to Java 17? Kwik and Flupke target 11, and the patches don't appear to
have any kind of requirement for newer features, though at the same time I
do see the avaje-jex-parent enforces Java 21 too...

I don't need it at all, but I'm not a fan of throwing the source version up if
it would be like a five-LOC change to potentially get more users / use cases

[SentryMan]

Remember that jex exclusively uses virtual threads so that we can avoid needing to implement any async stuff

[mechite]

exclusively uses virtual threads

right.. didn't know that.
you learn something new every day

[SentryMan]

You can put in a manual override to use a regular executor, but the whole thing was designed with virtual threads in mind

[mechite]

random question... is the .impl package preferred here?

in Avaje projects the pattern I picked up was either — same package,
public interface SomeInterface ... & final ... DSomeInterface ...,
...or with a "subpackage" named .core for implementations

(I don't care — but consistency is gold)

[SentryMan]

consider me baffled, these transport tests are so flaky

[SentryMan]

this might be the fabled udp unreliability, I can't tell if it's a client or server issue, given the total lack of java webtransport clients in the ecosystem.

[SentryMan]

I think I get it, it was sending the data frames before the ssl frames, so just need a delay before sending data.