[bindings] Hide ffi types + basic debug info

[lrstewart]

Description of changes:

Some minor updates to the low level bindings:

• Adding some new enums to wrap the raw ffi types so the tokio bindings never touch c types.
• Added a couple new getters to help with debugging
• Cleaned up errors and debug messages

Call-outs:

I'm still not sure we're handling debug / s2n_strerror_debug correctly. It behaves more like s2n_errno than s2n_strerror_name or s2n_strerror. The debug string is set when an error occurs, but will be overridden by any later errors. It's possible we should be copying the debug string into an owned string when we capture the error code. But is allocating a string for every s2n error an issue?

Testing:

Added some asserts to the existing test.

Here's the debugging information printed from the example client and server:

Listening on 127.0.0.1:4433
Connection from 127.0.0.1:59418
TlsStream {
    connection: Connection {
        handshake_type: "NEGOTIATED|FULL_HANDSHAKE|MIDDLEBOX_COMPAT",
        cipher_suite: "TLS_AES_128_GCM_SHA256",
        actual_protocol_version: TLS13,
        ..
    },
}

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[toidiu]

just an observation: this seems alittle odd since we dont use the Success type and instead return len as c_int. Also it would be nice to have poll_io return CallbackResult here and have the downstream function handle the conversion.

[toidiu]

also wondering if CallbackResult should instead be called StatusCode so that its reusable for non callback types

[lrstewart]

I'm not trying to solve callbacks here-- that's for later ;) I'm just trying to hide the C types.

just an observation: this seems alittle odd since we dont use the Success type and instead return len as c_int

The interface of some s2n-tls callbacks is a little odd :( We can't use the Success value because success for this callback means a valid length, not a success status code.

it would be nice to have poll_io return CallbackResult here and have the downstream function handle the conversion.

There isn't really a downstream function here to handle the conversion-- this is a callback that will return to C code that doesn't understand Rust enums.

also wondering if CallbackResult should instead be called StatusCode so that its reusable for non callback types

I choose "CallbackResult" because a customer's only interaction with this enum should be writing callbacks, since we handle the status codes returned by s2n-tls APIs. And I would love to remove that interaction too xD