Add JA3 fingerprinting

[lrstewart]

Description of changes:

Add JA3 fingerprinting functionality. For now, it's not publicly accessible.

JA3 is a method for identifying clients. See this blog post from its creator: https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/

We provide two methods, one to retrieve the full JA3 string and one to retrieve just the hash of the JA3 string. While the hash should be sufficient to identify a client, some customers have requested access to the full JA3 string.

Callouts

• For now, the API will error for SSLv2 ClientHellos. Clients would only send SSLv2 ClientHellos if they're unsure whether a server supports SSLv3 or higher. Since SSLv3 was released in 1996 and deprecated in 2015, I imagine we can live without SSLv2 support. If not, we can add it, but it complicates some of the parsing. SSLv2 JA3s also likely won't be particularly useful, since the only fields available are the protocol version and the cipher suites.
• If a customer wants both the full string and the hash, we calculate the JA3 string twice, once for each API call. But at least there's some benefit from this duplicate work: we can calculate the length of the JA3 string while calculating the hash, allowing a customer to allocate the correct amount of memory for the variable-length JA3 string.
• I didn't end up managing to reuse nearly as much of our parsing as I'd hoped. Luckily, most of the parsing we do is pretty simple.

Testing:

I wrote unit tests and a small number of known value tests.

In the future, I'd like to add fuzzing and call the API in s2nd so that it gets run for all the integration tests. Let me know if you have other testing ideas!

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

[goatgoose]

Still reading the tests!

[camshaft]

Do we really need a table for this? https://godbolt.org/z/4dcro7MK3

You should be able to just

ENSURE_EQ((byte1 | 0xF0), 0xFA);

[lrstewart]

https://www.rfc-editor.org/rfc/rfc8701.html

These values were allocated sparsely to discourage server implementations from conditioning on them.

You're messing up the GREASE strategy Cameron, they're supposed to be hard to match on :)