Changes from async-kwik

[mechite]

Enumeration of changes from async-kwik.
This is a draft PR as a cleanup of the very big patch @odanielmeinicke made

Signed-off-by: Mahied Maruf <contact@mechite.com>

[mechite]

I could not get the build system working properly to run all tests, but I resolved all conflicts and minimized the patch.
I am not confident in this PR

@odanielmeinicke 6121bb2 shows a bug in your code?
You never wrote to that collection, I couldn't figure out what you were trying to do with it
Since this pool is making a single-thread executor, I removed the collection entirely

[odanielmeinicke]

Hi, i appreciate the time you spent on my async-kwik, you've done a really good job here; But take as a note this code is a pure jerry-rig, i've made it in literally one day just to validate an other project that needed the kwik to be async for scalability, there's no tests and advanced code revisions for it. Anyways, i tested it on my library everyday since i publicated it initially and for now, there's no issues (for now)

As this code is a pure jerry-rig, we can collab each other and create something more elaborated for Kwik. Feel free to contact me in that case.

ME, PERSONALLY, the original creator of these changes DON'T recommend these changes (That's why i didn't pulled originally. Not because of the bugs, that can be tested; but because the mechanic of the listeners as interfaces, there's similar, but better ways to do that) for the official Kwik library.

Again, thank you for your time, you really made a good work. I analyzed every commit.

---

Also:

6121bb2 shows a bug in your code?

Not exactly, but yes. That's an incomplete feature to prevent stack overflow. As example: If i do a StreamInputStream#read inside a StreamReadListener#read(QuicStream, long), it will call it again in a loop and may break the implementations if not prepared for that (99% of them, and it's hard to create a "protection" system for that), that's also why i didn't recommend it

[mechite]

I think with proper testing the changes should be acceptable.

I'll be honest and say that the long/verbose method names like setStreamReadListener rather than e.g. onRead, and perhaps marking of this also as experimental API (if applicable annotations exist), might end up being an advantage to creating new public API that can later also be regressed (and allowing these changes to be pulled easily)

I think that the design of Kwik being the way it is, is probably just because of time constraints.

I just wanted to keep this PR down to:

• whatever you may have wanted to improve asynchronicity of Kwik
• provide virtual threads support (combined with Use Virtual Threads when on JDK 24+ #74)
• use e.g. long where int used, add more atomicity, and test
  (to fix "connections/streams limit" you suggested might be an issue)

...as this can maybe make Kwik scale up more.

Then, maybe in seperate PRs:

• JSpecify @NullMarked/@Nullable
• Some kind of JMH benchmark, to help @ptrd for improving performance?