Now that recently removed mix messages are independently cached for a
short period, this reverts the change that only removed spent pair
requests from previous block transactions to make it track the current
best tip again.

For reference, the change was originally made 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.

However, as noted when the change was made, while it was a quick way to
address the stated scenario, it doesn't deal with large reorgs nicely.

The new method is much more robust and works under all scenarios, so it
is preferable for the mixpool to track the current tip.

The current logic attempts to maintain at least one mix capable outbound
peer to ensure better connectivity among the mix capable peers.  It
works as intended, however, only having a single mix capable peer means
there will be delays if that peer goes offline until a replacement is
found.  A possible consequence is that any mix clients might potentially
get interrupted if that peer goes offline and a replacement isn't found
quickly enough.

Attempting to maintain a minimum of three mix capable outbound peers
will significantly reduce the likelihood of having periods without any
mix capable peers.

This updates the logic accordingly.