zio-http should not pull in incubator uring transport

[russwyte]

My organization just experienced a pretty significant issue where a library (lettuce) which also uses netty - found netty-incubator-transport-native-io_uring on our classpath and used it because zio-http pulls it in as a dependency. We had recently introduced a zio-http based client library.

The uring driver exhibits behavior like this in some cases:
netty/netty-incubator-transport-io_uring#247

IMO netty-incubator-transport-native-io_uring should be a transport option - but it should require an explicit dependency by a project using zio-http. I think this should be documented instead of provided by default.

Lettuce redis client has (IMO) a pretty unexpected and dangerous way of choosing the uring transport just because it's on the classpath. We are opening an issue up there as well. See here:

https://github.com/redis/lettuce/blob/0ccdde3b4aaac847c5615070354d9e5a47377dc8/src/main/java/io/lettuce/core/resource/IOUringProvider.java#L49

Because a high traffic area of our app uses lettuce and it was choosing uring transport - as it was on the classpath - we experienced a lot of IO waiting that slowed down critical APIs which had a very adverse effect.

We added a specific exclusion in sbt to get that library out of the classpath - but I don't think that should be necessary.

excludeDependencies ++= Seq(
  "io.netty.incubator" % "netty-incubator-transport-native-io_uring",
 ...
)

Incubator libraries are experimental and as such should be strictly opt-in.

[987Nabil]

@russwyte I think you are right. Especially in the light of auto select the transport mode. I would not be surprised if other netty based lives would do the same