Tls support2

[ollls]

test fix, ignore

[ollls]

Just want to provide some comments.

1. As John De Goes Said: "I'd rewrite that code to be "bare metal" and wrap the entire process in ZIO, for higher performance." It certainly doable but If you perform ZIO-NIO read() - it's an effect and you need to wait till it finishes to perform SSLEngin.unwrap() - which is another effect, so at least we have two effects chained together anyway. Not much for bare metal optimization. Also, primitive ByteBuffer ops, for example compact() are made as effects too. So, why not to present wrap()/unwrap() as a standalone effects in that case. Also, that approach allows to build SSLSocket on top of regular ZIO-NIO socket. If this to be made a "bare metal", there will be a code duplication with dubious performance benefit. Or maybe we don't use ZIO-NIO at all, and just work with NIO completion routines: bare metal and consider ZIO to be a high-level wrapper. Anyway. Here was an idea to use ZIO fibers as parallel primitives for paralel HTTP alike server. Not sure, if this good idea, but that what I was trying to achieve. It makes possible running parallel IO effects on just one CPU core. ( at least in theory ).
   Also... It may be interpreted that ZIO-NIO itself is too low level to be used with ZIO IO model ???

2. this is just FYI. The way TLS Support is designed it supports arbitrary buffer sizes, if you read extra data and cannot decrypt it right away it will be saved in carryover buffer for next read. Basically, we use ZIO fibers as a parallel supervisor and here we managed to avoid using two layered IO model, which is used for example in Blazer/https4s. This is in some sense a "poor man" parallel server IO. But to me it was worth trying.

3. Looks like that code won't find a place inside of ZIO-NIO. But I cannot externalize it, without removing protected qualifiers on some functions like bufferRead/Write in ZIO-NIO.
   It will be very likely that I just cut and paste ZIO-NIO's "wrap()" and implement everything separately. So, maybe this is a reason to think about how to make ZIO-NIO more open to third party access based on Java NIO ByteBuffers. In other words: if ZIO-NIO had native java NIO Buffer interface it would be much easier to use it as low level asynchronous scheduler for Java NIO completion routines.

But from what I learned, ZIO is considered to be more of a high level engine. And maybe this is what drives design decisions on ZIO-NIO as well.

Just thoughts...
Thank you Przemyslaw Wierzbicki, @quelgar, @jdegoes for your time and comments.