Utilize anti-DoS headers download strategy

Summary:
Avoid permanently storing headers from a peer, unless the headers are part of a
chain with sufficiently high work. This prevents memory attacks using low-work
headers.

Designed and co-authored with Pieter Wuille.

This is a partial backport of core#25717
https://github.com/bitcoin/bitcoin/pull/25717/commits/551a8d957c4c44afbd0d608fcdf7c6a4352babce
https://github.com/bitcoin/bitcoin/pull/25960/commits/132ed7eaaa4a47ab94db72ebfab0ef0e03caa488 (use NET logging category)
https://github.com/bitcoin/bitcoin/pull/26172/commits/bdcafb913398f0cdaff9c880618f9ebfc85c7693 (bugfix)

Depends on D15125
Notes:

• I added SaltedBlockHashHasher because it didn't seem right to use SaltedTxidHasher. In practice, they all do the same as the generic SaltedUInt256Hasher.
• I made two of the "Initial headers sync aborted..." log messages unconditional instead of logging into the NET category. They should not be printed very often, and it is valuable information for debugging from logs shared by users. Without this, we would have to guess the problematic block height from the headersync percentage (logged only once every 2000 blocks).

Test Plan:
ninja all check-all

Start a node on mainnet with a fresh download dir. Check that it catches up with theader sync and starts downloading blocks.
Repeat with tesnet.

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Subscribers: Fabien

Differential Revision: https://reviews.bitcoinabc.org/D15129