…end_clawback_coins

…ve_ignore_max_send_amount

…tx_pushing_optional

…awback_coins

…tx_pushing_optional

…ve_ignore_max_send_amount

…awback_coins

…ve_ignore_max_send_amount

…tx_pushing_optional

…awback_coins

…ve_ignore_max_send_amount

This is a very old parameter that we've been propogating through new
version of generate signed transaction for (it seems to me) no reason.
The only instances in which this parameter is actually set to `True` we
manually specify the set of coins anyway. Perhaps the idea is to prevent
choosing coins that won't fit in a block, but such an unlikely error
will still get caught by the mempool and there's a million other similar
errors that would behave that way as well. I think more likely the
intention was simply for testing in tests that have since been
re-written or deleted.

…tx_pushing_optional

…awback_coins

This PR is a step in the direction of a more observer-style wallet.

Currently, most of our wallet functions just push directly to the
network as a matter of course when creating a transaction. While this is
convenient (especially in tests) it will be impossible should we get to
a wallet design that does not contain the private key as a key component
to wallet operations.

For now, the wallet still signs the transaction and has it ready to be
pushed to the network should the user specify that. But all of the
pushing logic has been migrated to the top-most layer available (usually
the RPC) so that the user always has control over whether or not they
would like to immediately push the transaction.

In addition, any transaction method in the RPC now returns a
`"transactions"` key so that it is easy for a front-end client to have
everything they need to push the transaction as if the wallet was doing
it (using the `push_transactions` endpoint).

…end_clawback_coins (#16354)

Previously, this logic depended on pushing clawback transactions to the
wallet DB to be submitted so that on further transaction generations,
the same coins would not be selected. With the change to make all
transaction pushing optional, this logic no longer functioned correctly.
This change leverages the `excluded_coin_ids` key in the `TXConfig` to
exclude coins between transaction batches instead, resulting in a
stateless generation of these transactions (fitting the new pattern).