Naming conventions

[Matt Caswell]

PRs #11996 and #11997 made some changes to the EVP_MAC and EVP_KDF API
naming conventions. Specifically (in the MAC case) renaming:

EVP_MAC_CTX_new -> EVP_MAC_new_ctx
EVP_MAC_CTX_free -> EVP_MAC_free_ctx
EVP_MAC_CTX_dup -> EVP_MAC_dup_ctx
EVP_MAC_CTX_mac -> EVP_MAC_get_ctx_mac
EVP_MAC_CTX_get_params -> EVP_MAC_get_ctx_params
EVP_MAC_CTX_set_params -> EVP_MAC_set_ctx_params

There are similar renamings for the KDF APIs.

I am opposed to this renaming on the basis that it is inconsistent with
what we do elsewhere. For example, except for the MAC/KDF APIs I see
there are 26 functions of the form:

FOO_CTX_new

The case is similar for FOO_CTX_free. Aside from the newly introduced
MAC/KDF names there are no other instances of FOO_new_ctx or
FOO_free_ctx. This is totally inconsistent and, IMO, will cause
significant confusion for our users.

I will let others describe the rationale and arguments in favour of the
change, because I wasn't involved in those discussions.

I have proposed a PR to revert the changes (12186) which has an OTC hold
on it pending the discussion that I hope to kick off in this thread. As
I wrote in that PR:

"If we want to change the naming conventions then we should do so only
after agreeing what those conventions should be, and agreeing a strategy
for how we are going to apply them. It should not be done piecemeal (and
hidden away in a PR that supposedly made things more consistent but in
reality did the opposite)."

There *are* inconsistencies and quirks in our current naming
conventions. I am skeptical that now is the time to resolve them given
the number of other changes we are already introducing into 3.0. I'm
also skeptical about introducing changes to well established APIs that
have been used for many years out of some purist sense of order.
However, I'm willing to listen to the arguments on that.

Thoughts please?

Matt