When a peer responds to an unknown mix message and this does not result in a
ban, the requested message must be removed from the sync manager's current
state for in-flight requested messages.

Instead of removing PRs spent by the latest tip block attached to the main
chain, use the previous block.  The goal of this is to avoid immediately
removing mixpool messages that are still propagating the network when a block
was quickly mined which includes transactions created from those very same mix
messages.

After taking a second look at this, this method of removing completed sessions
from mixpool does not deal well with reorgs.  Using the previous block for
every main chain tip extension or reorg will work better, but will still not
handle a 2+ block reorg properly.  However, these mixpool messages are only
removed to avoid a memory leak, and the messages would simply be removed at a
later time due to PR expiry.

Previously, outbound peers were required to have a newer minimum
protocol version than inbound peers, so two different checks were needed
to differentiate.

However, now that both inbound and outbound peers are required to have
the same minimum version, there is no longer any need to have both
checks for the same thing.

Thus, this removes the additional check that is no longer needed.

If a transaction is rejected because it reference unknown previous transaction
outputs and orphans are disallowed, provide the particular outpoints that are
missing, not just transaction hashes.

This adds logic to attempt to help maintain at least one mix capable
outbound peer to ensure better connectivity among the mix capable peers.