Update send system

[SeanTAllen]

The way send works right now is very "modeled after stdlib/net" which isn't a great model for Lori.

Changes to make:

• send becomes partial. if at the time of a call, the send can't happen, because connection has yet to be established, or has been closed, or backpressure, or otherwise unwriteable, do an error. (return code is possible here as well as the API evolves during this design)
• remove the "pending data" array that is used on posix. we can maintain ownership of the data from the enclosing actor and maintain merely an offset into the data. given the "send becomes partial" then we wouldn't ever have more than 1 item in the "pending data" array.
• provide a way to track when a given chunk of data has been "sent" aka handed-off to the OS. we need to provide some means (perhaps a "send token") so that we can inform the actor at a later point that the data has been sent. either this means that we require a send token on send (tcp connection could manage the creation of the tokens) or we supply a token as a result from send (in which case, send isn't partial but rather returns a token or none depending on success).
• as part of the "way to track when a given chunk has been sent", we need a callback for data having been sent. we have _on_send already so _on_sent makes sense.
• we should have a "writeable" query method on the connection that can allow the enclosing actor to determine if the socket is writeable.

These changes will make the decision to queue when backpressure is experienced vs dropping data an application level concern rather than a library level concern.

[SeanTAllen]

Making this work in a way that isn't janky with SSL probably requires rethinking how SSL is implemented. It is currently modeled after the standard library's interaction with net_ssl which doesn't make any sense in light of the above desired requirements.

Take how SSL sending is currently done. All calls to _on_send are intercepted and it puts the outgoing data into an SSL write buffer and then starts doing a ssl_poll that will eventually send the data. There's no visibility here into when the data is sent. It could in theory be buffered forever.

The _on_send documentation says:

    """
    Called when data is about to be sent on this connection.
    This allows for protocols like SSL to hook in and modify the outgoing
    data.

    Return None to indicate that no data should be sent.
    """

The "None to indicate that no data should be sent" means different things in different context. In the context of SSL it means "do not send because I am going to try to handle it". So things that could happen with _on_send. It could return the a ByteSeq so that TCPConnection will send it "like normal". It could return None which TCPConnection will then take to mean "do not send" and it won't send "like normal". As the current SSL shows, this could mean the data is going to attempt to be sent. Also for SSL, if we get a write error, we return None which doesn't mean "it is going to be sent", it means "can't send". That is already a "not very good" API.

SSL works at the moment but the API is problematic.

Ideally when we call send on a connection we can know if we are able to send. This means is writeable on the underlying socket + any additional information that something like SSL that wraps it would provide. So it the case SSL that would be we have completed the handshake and are ready to go.

If both conditions aren't true we get some sort of error code back from TCPConnection.send otherwise, SSL "directly sends" the data on the underlying socket. Ideally this can be done without the SSL implementation being part of the same package.

With the existing SSL class, we could accomplish this by:

• _on_send checks the SSL status to see if we can proceed (how do we handle the writeable check on the base socket?
• if we can proceed, we call SSL_write to add to the buffer for the connection then do a BIO_read to get the data and ship off for "actual sending".
• if actual sending is "just on TCPConnectionthen_send_final` needs to be public so that it can be called from outside the package. and it is responsible for letting you know how much data was actually send (which would track back to the encrypted buffer size, not the size you gave us).
• ideally we don't want _send_final to be public as that allows for misuse of the API however, it feels like a decent step for "right now" to get this working if the other issues above can be worked out.