Only try ticket purchase when enough balance.

[jholdstock]

This fixes a bug where purchaseTicket was called on every block if mixing is enabled, regardless of whether there was sufficient balance to make a purchase.

This resulted in a new address being generated on every block and it being left unused.

Code is simplified by splitting out the validation of the ticketbuyer config (which has an extra benefit of ensure it only runs once) from the logic which determines how many tiickets can be afforded.

[jholdstock]

Rewritten with your comment in mind. Config is now reconsidered on every iteration, and mixing with limit>1 is now allowed.

[jrick]

This may also have a negative performance impact on some of the larger wallets, since calculating the balance on these can be quite expensive (much more so, as it has to iterate over all utxos, vs. randomly selecting inputs to fund the purchase until a sufficient amount of value has been included). I recall this being noticed before by some people (can't recall who) because they had the balancetomaintainabsolute option set.

[jholdstock]

mixing with limits over 1 are frequently used on both production (mainnet) and testnet wallets.

I just remembered a different bit of code is responsible for mixing&limit>1. That means that this behaviour is unaffected in both the first and second versions of this PR.