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.

#include <wallet/coinselection.h>
#include <consensus/amount.h>
#include <policy/feerate.h>
#include <util/check.h>
#include <util/system.h>
#include <util/moneystr.h>
#include <numeric>
#include <optional>
namespace wallet {
struct {
    bool operator()(const OutputGroup& a, const OutputGroup& b) const
    {
        return a.GetSelectionAmount() > b.GetSelectionAmount();
    }
} descending;
/*
 * This is the Branch and Bound Coin Selection algorithm designed by Murch. It searches for an input
 * set that can pay for the spending target and does not exceed the spending target by more than the
 * cost of creating and spending a change output. The algorithm uses a depth-first search on a binary
 * tree. In the binary tree, each node corresponds to the inclusion or the omission of a UTXO. UTXOs
 * are sorted by their effective values and the tree is explored deterministically per the inclusion
 * branch first. At each node, the algorithm checks whether the selection is within the target range.
 * While the selection has not reached the target range, more UTXOs are included. When a selection's
 * value exceeds the target range, the complete subtree deriving from this selection can be omitted.