TLS layer: c->rtls to optimise recvd TLS data

[cpq]

The reason for this PR is to minimise the amount of data copies for the TLS case. TLDR: raw data is now received in the c->rtls IO buffer, and can be accessed directly.

So, receive path:
stack receives new raw data -> c->rtls -> (TLS decrypt) -> c->recv

Note that the send path does not have the same. Apparently, TLS implementation can just encrypt data (mg_tls_send()) data on-the-fly.

Right now, the builtin receive path looks like this:

1. Stack. Packet data gets copied to the s->raw IO buffer
2. Stack. Call mg_tls_recv
3. TLS. mg_tls_recv copies data in its own recv buffer
4. TLS. mg_tls_recv decrypts the data and returns
5. Stack gets decrypted data and copies into c->recv

This PR unifies receive path to all TLS implementations by creating c->rtls IO buffer for the raw, encrypted data.

This change required OpenSSL implementation be changed, because OpenSSL accessed an underlying socket descriptor directly. Instead, OpenSSL must use our own low-level send/recv primitives for the low level IO - just like mbedTLS does. So, OpenSSL code was refactored: a custom BIO is created that implements the IO rather that relying on the socket. Theoretically, it makes it possible to use OpenSSL with the builtin stack - which is unlikely anyways.

[scaprile]

AFAICU, LGTM

[scaprile]

What is the reason for this ?

[cpq]

Ah, just a leftover. tls_builtin.c will be totally replaced soon, so does not matter, really.