Extract `ByteBuffer` into it's own module

[0xTim]

As more packages adopt Swift concurrency across the ecosystem, we're hitting cases more and more where we're pulling in NIOCore solely to be able to use ByteBuffer. It would be great if we could extract ByteBuffer into its own module (or even better own package) to provide a modern, consistent bag of bytes implementation for the ecosystem.

[Lukasa]

I’m fairly strongly opposed to this. It’s not a good pattern for the ecosystem to have NIO define currency types for use-cases outside of networking. Our intention is not to have NIO be an “un-standard library”.

It would be better, I think, for the SSWG to raise this need with the relevant steering group and come up with a position.

[0xTim]

Yeah we (the SSWG and steering groups) do need to come up with a position as to what should be done. The difficulty will be rolling it out in the ecosystem without necessitating copies between different types etc (we already hit issues when trying to use AsyncSequence<ArraySlice<UInt8>>

[Lukasa]

I 100% agree that that is the shape of the problem to be solved. I also want to make sure that the ecosystem as a whole, not just NIO, gets to participate in making that happen, which is why I'm reluctant for ByteBuffer to be the currency type. This problem is broader than Swift on Server: it affects interaction with the Apple platform SDKs (which pervasively use Data) and the standard-library-only ecosystem (e.g. embedded). Coming up with a good answer here requires a high level view of the problem space.