Implement kotlinx-io on the Okio library basis

[fzhinkin]

Okio is a popular, well-established, and battle-tested library providing rich functionality and good performance. It provides concise yet powerful primitives for multiplatform IO. kotlinx-io could use Okio as a basis.

The overall plan is to take the Okio library (its core part, without filesystems), eliminate a Java legacy from the API, reduce the API shape, and provide missing functionality and features.

One of the goals along this path is to ensure that kotlinx-io will preserve the same performance level as Okio has right now or even improve it where possible. To track the performance, a benchmarking suite should be added.

New functionality and features that could be considered for adding to the library in the future include:

• asynchronous IO support (see Introduce Async API #163);
• different memory types (in addition to byte arrays) Buffers are built upon (like NIO ByteBuffers on JVM) (see Support ByteBuffer as a backing storage on JVM #239);
• file system support (at the moment, it won't be taken from Okio) (see Files and FileSystems support #241).

Particular tasks will be described in corresponding GH issues.

[fzhinkin]

Currently, the development is conducted in prototype-preview branch (https://github.com/Kotlin/kotlinx-io/tree/prototype-preview).

[SPC-code]

Will Input/Output abstraction be separate from Okio? I think it is important since we will want to be able to use non-okio backend in future.

[StylianosGakis]

When I saw that the filesystem won't be carried over I thought maybe it's because you don't want this functionality to be here, but you do in fact mention later that it is a possible future feature, and explicitly stated that it won't be taken from okio.
Why is this the case I wonder, is it some specific thing you're trying to avoid, some design decision you don't agree with, or something completely unrelated?
I don't have personal opinions about it. I'm, mostly just curious about it.

[fzhinkin]

Sorry for the ambiguity, I only wanted to stress that we're not including Okio filesystems into kotlinx-io right now (and I didn't mean that we'll never consider Okio filesystems as a basis for kotlinx-io filesystems once the decision to develop it will be made).
So, yeah, there are no arguments against Okio FS, we're just not going to support filesystems right now.

[StylianosGakis]

Ah, thanks a lot, I really misunderstood what you meant in the original message. Reading it back again now I totally see what you just explained to me here. Thanks for the clarification, and sorry for the confusion 😊