Prepare to provide EVP_CIPHER_CTX_buf_noconst()

Prepare to provide EVP_CIPHER_CTX_buf_noconst()

This is just a dumb 'return ctx->buf' whose name was chosen to be consistent
with EVP_CIPHER_CTX_iv{,_noconst}() though there is no EVP_CIPHER_CTX_buf()

ok jsing

The backstory is this:

This wonderful API will be needed by MariaDB once EVP is opaque. To be able
to use its own handrolled AES CTR variant, it needs to reach inside the cipher
ctx's buffer and mess with it:

      uchar *buf= EVP_CIPHER_CTX_buf_noconst(ctx);
      /*
        Not much we can do, block ciphers cannot encrypt data that aren't
        a multiple of the block length. At least not without padding.
        Let's do something CTR-like for the last partial block.

        NOTE this assumes that there are only buf_len bytes in the buf.
        If OpenSSL will change that, we'll need to change the implementation
        of this class too.
      */

Being the dumb return ctx->buf that it is, the EVP_CIPHER_CTX_buf_noconst() API
obviously doesn't provide a means of doing any length checks.

If it is any consolation, it was committed with the vague hope of being a
temporary measure as OpenSSL commit 83b06347 suggests:

    Note that the accessors / writers for iv, buf and num may go away, as
    those rather belong in the implementation's own structure (cipher_data)
    when the implementation would affect them [...]

As is true for many temporary kludges and dumb accessors, these are here
to stay a with us for a while.

While I'm at it, MariaDB has other phantastic things it did to ease its
pain with the OpenSSL 1.1 API transition.

To avoid one of two allocations (we're talking about ~50 and ~170 bytes) per
EVP_{MD,CIPHER}_CTX instantiation, it defines EVP_{MD,CIPHER}_CTX_SIZE and
uses arrays of these sizes that it aligns, casts and passes as ctx to the
EVP API.

Of course, they need to safeguard themselves against the inevitable buffer
overruns that this might cause since the type is opaque and could (and actually
did) change its size between two OpenSSL releases. There is a runtime check in
mysys_ssl/openssl.c that uses CRYPTO_set_mem_functions() to replace malloc()
with "coc_malloc()" to determine the sizes that OpenSSL would allocate
internally when doing EVP_{MD,CIPHER}_CTX_new() and match them to MariaDB's
ideas of the ctx sizes.

Go look, I'm not making this stuff up.