tcp: Use jenkins_hash32() in hostcache

[rscheff]

Summary

While investigating the reported hostcache
issues and adding a histogram to look at the
distribution of used hashbuckets, and
bucketdepth, I found that the exteremly
fast XOR "hash" would result in a rather
skewed utilization of the hostcache, for
randomly selected remote IP addresses.

As other parts of the base tcp stack (eg.
tcp fastopen) already use jenkins_hash32,
and the properties appear reasonably good,
switching to use that.

Test Plan

Anecdotal evidence (single trial, using
approximately 1000 randomly selected hosts,
overall, but ~400 for XOR and ~600 for Jenkins):

Unused Hash buckets: XOR ~51%, Jenkins ~35%
Average Bucket Depth: XOR ~2.44, Jenkins ~1.54

[ae]

sys/netinet/tcp_hostcache.c

222

Maybe would it be better to use full IPv6 address to compute hash?

[ae]

sys/netinet/tcp_hostcache.c

222

ah, sorry for the noise :)

[rscheff]

transport call: initialize salt randomly, and change it when purging, when triggereing purge with "2" instead of "1".

[rscheff]

• initialize the hash salt with a random number
• reseed the salt when purging all entries with "2"
• adding man entries for all hostcache related sysctls

[rscheff]

• rebase to main