General cleanup

[qmuntal]

Important: This PR will be rebased into main once #1 is merged.

This PR contains 3 small but important refactors, each one in its own commit:

• c755e5e: Removes the concept of internal C function.
  It was previously used to indicate that a function was not called from Go but only from C. The thing is that there is no reason why a function should stay in the C world, its just an implementation detail where it is used. The drawbacks are many: adds cognitive load for a developer to understand why a C function starts with _goboringcrypto_internal_ and others just with _goboringcrypto_, complicates documentation, promotes code duplication (i.e. to wrap internal functions), increase PR differences when a internal function is promoted to non-internal, etc...

• a78b533: Remove GO_ identifiers.
  There are some OpenSSL enums and types that are copied and renamed adding a GO_ prefix to them. Fedora did that to reduce diffs with the boring branch. Google has a good reasoning for that: they don't require BoringSSL headers to be present when building the Go, so they just redefine the necessary BoringSSL types. Fedora nor us do that, we require OpenSSL headers to be present, so we end up using a mix of GO_ and native types, which is confusing and noisy without any benefit. It would be good to avoid requiring openssl headers at build time, but this is a property that requires great care and we are not prepared to provide it yet.

• c1eb005: Rename all boringcrypto strings to openssl.

[dagood]

It looks like _goboringcrypto_HMAC_size(h.ctx) used to get md from the context then check its size, but now we're using "our" pointer to md to get the size. I imagine that since we just called go_openssl_HMAC_Init_ex, there's no possibility that ctx and md disagree, but wanted to ask, to make sure.

[qmuntal]

That's correct, it was a meditated changed. In fact OpenSSL 1.0.2 implements HMAC_size as a macro which expands to EVP_MD_size((e)->md)) and it is deprecated from 3.0.0.

We could of course miss to call HMAC_Init_ex or set the wrong md, but if that happens there are a couple of unit tests that would fail.

[qmuntal]

It looks like _goboringcrypto_HMAC_size(h.ctx) used to get md from the context then check its size, but now we're using "our" pointer to md to get the size. I imagine that since we just called go_openssl_HMAC_Init_ex, there's no possibility that ctx and md disagree, but wanted to ask, to make sure.

While looking at HMAC_size again I noticed that HMAC_CTX_get_md was only being used in there, so it can also be removed.

It then turns out that the only use of a hmac_ctx_st field was inside HMAC_CTX_get_md, so if we remove HMAC_CTX_get_md we can also change the definition of hmac_ctx_st to be a plain unsigned char _ignored0[0x120] (aka we don't care about which fields it contains, treat it as a memory blob).

This change has been implemented in 993e8a7.

And that's not all! There was a bug in the hmac_ctx_st definition, which was causing tests failures when building with OpenSSL 1.1.x and running with 1.0.2. This bug has been fixed by correctly representing that structure as a char array of 0x120 bytes.

[dagood]

Would it also be accurate to point out in the comment that 0x120 is the maximum sizeof value between 1.0.2 and 1.1.0? Or is that not what's going on here?

Maybe it would be possible to put together a check that makes sure our bridge definitions match/exceed the size of the OpenSSL structs when compiling against the target version of OpenSSL? (So the 1.0.2 build job could have caught this directly?)

[qmuntal]

Hmm, interesting. It should be possible to catch this errors at build time when using the bridged version. I will give it a try in another PR!