While regtesting with [bitcoin-spock](https://github.com/msgilligan/bitcoin-spock) I noticed at some point the transaction creation via `sendtoaddress -> CreateTransaction()` fails, because the created transaction is larger than `MAX_STANDARD_TX_SIZE`.

During the process a lot of raw transactions are created, which have smallish outputs and when then using `sendtoaddress`, it appears to attempt to create a transaction that spends too many of those dust-ish outputs.

The transaction to create does not have many outputs, but it looks like it's caused by the coin selection, which selects too many inputs. Testing was done with a 0.9 branch, but on the first glimpse I believe this issue is as well be present in 0.10. If this is a known issue, and if there is already a guard against this behavior, I'd be happy about a hint.

Sorry in advance, I do not have a test script to reproduce this issue in an isolated manner. A potential fix would probably require to adjust the coin selection, so that it selects a combination of coins, which, in addition to the size of the rest of the transaction, is still smaller than the limit.

* where excess = selected_effective_value - target
 * change_cost = effective_feerate * change_output_size + long_term_feerate * change_spend_size
 *
 * Note this function is separate from SelectionResult for the tests.
 *
 * @param[in] inputs The selected inputs
 * @param[in] change_cost The cost of creating change and spending it in the future.
 *                        Only used if there is change, in which case it must be positive.
 *                        Must be 0 if there is no change.
 * @param[in] target The amount targeted by the coin selection algorithm.
 * @param[in] use_effective_value Whether to use the input's effective value (when true) or the real value (when false).
 * @return The waste
 */
[[nodiscard]] CAmount GetSelectionWaste(const std::set<COutput>& inputs, CAmount change_cost, CAmount target, bool use_effective_value = true);
/** Choose a random change target for each transaction to make it harder to fingerprint the Core
 * wallet based on the change output values of transactions it creates.
 * Change target covers at least change fees and adds a random value on top of it.
 * The random value is between 50ksat and min(2 * payment_value, 1milsat)
 * When payment_value <= 25ksat, the value is just 50ksat.
 *
 * Making change amounts similar to the payment value may help disguise which output(s) are payments
 * are which ones are change. Using double the payment value may increase the number of inputs
 * needed (and thus be more expensive in fees), but breaks analysis techniques which assume the
 * coins selected are just sufficient to cover the payment amount ("unnecessary input" heuristic).
 *
 * @param[in]   payment_value   Average payment value of the transaction output(s).
 * @param[in]   change_fee      Fee for creating a change output.
 */
[[nodiscard]] CAmount GenerateChangeTarget(const CAmount payment_value, const CAmount change_fee, FastRandomContext& rng);
enum class SelectionAlgorithm : uint8_t