Reconsider API design about tokio-uring

[Noah-Kennedy]

I'm currently working on this but it's blocked behind another PR which I need to push through first. Hopefully I get the "refactor the runtime to use internal handles" PR up tonight as planned, so that I can resume working on this.

[Noah-Kennedy]

An update on this: #244 kicks off the start of this, initially for only oneshot operations.

[Ralith]

In Quinn, we currently bypass tokio 1.0 I/O APIs entirely because they can't possibly express the eclectic collection of options and ancillary data we rely on (e.g. IPV6_TCLASS, IPV6_PKTINFO, their IPv4 analogs, UDP_GRO, UDP_SEGMENT, etc). Something more scaleable would be nice! These interfaces can be pretty diverse, though, so accounting for every possibility may be difficult.

[Noah-Kennedy]

@Ralith I know the feelling quite well, and I was actually thinking about some similar issues we've had at work related to the tokio APIs when I came up with this proposal.

I also think that, as a cop out, we could also expose a function which allows "raw" events to be submitted.

[mzabaluev]

The explosion of methods exemplified by #184 make me support the idea of builder APIs.

Something like this would be nice:

let n = file.build_write()
    .fixed(buf)
    .at(pos)
    .start()
    .await?;

It may be even possible to eliminate Slice and provide a way to multi-slice a buffer for compound operations:

file.build_write_all()
    .buf(v)
    .multi()
    .slice_at(..5, 0)
    .slice_at(7..10, 5)
    .start()
    .await?;