The submit queue channel was not actually increasing any performance.
(*peer).submit() would synchronously wait for all error results, and the call
to (*Wallet).SubmitMixMessage was already synchronized by the mixpool mutex.

Furthermore, this also fixes a deadlock that was observed after a mixing
wallet with the RPC syncer mode reconnected to a restarted dcrd.  Pair request
messages were being submitted onto the channel with the client mutex held in
(*Client).Dicemix.  However, handleSubmitQueue had already exited and the
client had not yet been restarted after dcrd reconnect, and was unable to be
started due to the locked mutex.

The client mutex was being held during the initial publishing of pair request
messages to prevent a situation where a submit errored but the peer was still
associated with the client, or the message was submitted to mixpool and sent
to other peers but our local peer had not yet been associated to the client at
the time an epoch tick occurred.  This should not be a situation we will
encounter anymore, since the PR submissions are spaced out intentionally to
avoid sending them close to the epoch.