feat(core): io_uring prototype

[puzpuzpuz]

Refs #1867

WIP, as early as it can be

TODOs

• Add more operations
• Consider getting rid of liburing or at least avoid linking
• Think of a more convenient API
• Make sure that we check ulimit -l on startup and suggest the user to increase the limit

Sample

try (IOUring ring = new IOUring(rf, 32)) {
    long id = ring.enqueueRead(fd, 0, bufPtr, bufLen);
    if (id == -1) {
        // ring is full
    }
    // enqueue more operations ...
    ring.submit();
    
    // start waiting for them
    while (!ring.nextCqe()) {
        Os.pause();
    }
    long completedId = ring.getCqeId();
    int completedRes = ring.getCqeRes();
    if (completedRes < 0) {
        // operation failed
    }
    // do something with the buffer 
}

[bluestreak01]

Looking very good! Ideally we'd need windows and OSX abstractions too, so that Java impls don't have to suffer.

Additionally, core/src/main/resources/io/questdb/bin/linux/libasm.a does not need to be checked in, common mistake

[puzpuzpuz]

liburing will very likely go away entirely.

As for having a single abstraction for all async file APIs, it's tricky. The usual approach is to implement it via a thread pool.

We could do that or try to implement different behavior on Linux only. I'd propose to finalize io_uring API on its own, merge it and then try to come up with a common abstraction separately.

[puzpuzpuz]

@eugenels thanks for dealing with cmake and static linking!

[ideoma]

[PR Coverage check]

😍 pass : 102 / 116 (87.93%)

file detail

	path	covered line	new line	coverage
🔵	io/questdb/std/IOUringFacadeImpl.java	23	29	79.31%
🔵	io/questdb/std/IOUring.java	55	62	88.71%
🔵	io/questdb/std/IOUringAccessor.java	24	25	96.00%