TLS handshake performance investigations (post-#428)

[hlandau]

Following from #428

These should be prioritised based on the descending order in #428 The below list is sorted accordingly.

### Tasks
- [ ] https://github.com/openssl/project/issues/440
- [ ] https://github.com/openssl/project/issues/445
- [ ] https://github.com/openssl/project/issues/443
- [ ] https://github.com/openssl/project/issues/446
- [ ] https://github.com/openssl/project/issues/447
- [ ] https://github.com/openssl/project/issues/442
- [ ] https://github.com/openssl/project/issues/444

See also: https://github.com/openssl/openssl/issues/20286

[hlandau]

This is the output of the performance meeting of 2024-02-01. We have generated a set of investigation tasks driven by the findings of #428.

These are investigation tasks not "design a solution" tasks, but will inform the design process. So subsequent engineering tasks will come out of these tasks.

[nhorman]

something I just noticed, the namemap code also supports reverse lookups, which are implemented by iterating over the entire hash table. That can't be particularly efficient. Are namenum entries bidirectionally unique? i.e. does a number map to exactly one name? If so we could implement an efficient reverse lookup with an extra key

[mattcaswell]

No. A name can have many aliases. All the aliases point to same number.

[t8m]

However for some use cases of mapping of ids to names giving out just one name - preferably the first one entered in the namemap, would be sufficient. Or you could have a map that maps ids to a list of names.