Fix the approach so that instead of stopping avalanche on the inconclusive item, we continue
with a reject vote. This way, we retain network consistency but are still able to tip the
network to finalize a rejection and not let a vote dangle.

Generally true throughout this diff: the naming is too dependent on the underlying proofs database being a radix tree. A simple example at the peer manager interface is getProofRadixTree(). Does the caller care that the DB is a radix tree? If we change to some other COW DB, we'll end up with a lot of renaming to do.

Maybe mention in the summary that changes related to g_wtxid_relay_peers are not present because these are for segwit.

Attempt to handle unexpected DUPLICATED case gracefully

A quick mention of what you intend to do with this would be helpful since it's not currently used except for its own test.

This single flag is trying to do two jobs, so it ends up being a tri-state switch, which I doubt is expected by the user:

• Unset - non-avalanche connections do not bypass, but avalanche connections do
• True - all connections bypass
• False - no connections bypass

done