In future releases, expired PRs will be handled by creating a new PR for the
existing client call, so there will be no need to detect or expose this error.

While here, add additional context describing the PR which expired.  This info
is not terribly useful to the caller, but it is only temporary until expired
PRs are eventually recreated with a higher expiry.

In the case that blame assignment occurs, create a frech allocation for a new
slice of PRs instead of writing into the memory of the previous slice.

The particular reasons why any peer might be blamed directly from run (rather
than during full blame assignment after revealing secrets) was unclear, so
include this info in the debug log.

This allows us to remove an unnecessary log from the wallet (which was only
being done in RPC mode and missing from SPV).

The MixPRs method has been modified to remove the query parameter, as it was
only ever called with nil.

The RPC server no longer needs access to directly call RemoveConfirmedMixes.
This same operation is already (and incorrectly) done by MixPRs, and it will
need the eventual fix.

One exception: we are keeping RemoveConfirmedMixes which is still not used
anywhere.  This method behaves similarly to RemoveSpentPRs but removes mixes
that completed with a confirmed coinjoin transaction matching any of the
provided hashes.  This may be used later by wallet to remove mixes that
include transaction hashes in the merkle tree, while dcrd can just provide the
mined transactions themselves and remove anything that double spends a PR
UTXO.

If an invalid UTXO signature in a pair request message is received from any
node besides a full node, reject the message but do not ban for the error.
However, full nodes are required to check this before relaying.  Ban any
self-reporting full node that still sends these invalid messages

Because the banning logic is currently isolated to the mixpool package and
mixpool is unaware of the capabilities of the peer that provided the message,
give IsBannable an additional service flags argument.  This changes the
semantics of the bannable errors to only be bannable when all of the required
service flags are described.

In order to meet the standard tx size requirements on mainnet, peers who
contribute too much to the coinjoin transaction size must be excluded from the
current run before the pairing is finalized.  Failing to do so will only
result in a transaction that fails to publish if all peers continue the mix to
completion.

Exclusion is performed by iterating all current PRs in the random order
determined by the set of all PRs and the current epoch.  A fake coinjoin
transaction which is only meant to measure the expected tx size is added to
only if that peer does not overcontribute to the size.  The random peer order
is sufficient to prevent this algorithm from being gamed.

Any peers that become excluded will attempt a mix again in the following
epoch.  While it could be possible, we do not currently run multiple mixes for
the same pairing type by splitting the PR set into two or more sets.

This simplifies the code significantly while simultaneously making mixpool
acceptance checks stricter in ruruns after blame due to the session validation
and PR inclusion rules that were only being performed during run 0.

This avoids an issue where peers who have been excluded in a later rerun
continue to submit messages in the rerun.  These messages were not being
correctly rejected by mixpool, and could be improperly received by clients.
Rejecting these messages would have required wallets to provide additional
hints to the mixpool about which peers are still in the rerun, and this
information would be unavailable to dcrd mixpools entirely.

Instead, a new run-0 session is formed with a subset of the original peers,
and all of the existing run-0 validation would continue to be executed for the
rerun.  mixpools no longer understand the difference between reformed sessions
and reruns, and will refuse to accept any non-run-0 message.

In the future, this may also be useful to observe new rerun sessions that
other peers have tried to create that differ from our own, which will be
useful first step in debugging why these sets differ.

This is technically a breaking change that will stop rerun mixes for older
wallets who do not also create the same new sessions, but this only affects
reruns after blame assignment and original run-0 sessions will continue to
operate properly if all peers are honest and behaving.

The two most recent merged pull requests merged cleanly but should have been
manually rebased to avoid breaking the build.

This updates the 2.0 release branch to use the latest version of the
mixing module which includes updates to respect maximum standard
transaction size limits and improvements to the blame assignment and
resulting rerun process.

In particular, the following updated module version is used:

- github.com/decred/dcrd/mixing@v0.3.0