was exiting with non-zero error code due to trying to copy directory
```
9cf9cdda331b565dd95b105d3fe987beefa113ac2c594d83783998017ad52d70 dist/electrum-4.1.4-16-g648fac709-portable.exe
020ceacb3a6fc5986d3ec271985c22c8646d2bb534536b8e2ab774924b21d58f dist/electrum-4.1.4-16-g648fac709-setup.exe
e65dbbe24fe01e8635d4def088667e65d4e9763e2ab74cbc1aec616b3f2834bc dist/electrum-4.1.4-16-g648fac709.exe
💬 INFO: Done.
cp: -r not specified; omitting directory '/home/user/wspace/electrum/contrib/build-wine/../../contrib/build-wine/fresh_clone/electrum/contrib/build-wine/dist/electrum'
```
Also update existing key with some signatures.
Now both keys have ThomasV's sig,
and they cross-sign each other.
I will use sombernight_releasekey to sign releases, and keep using the
older key to sign commits and other day to day stuff. As I use a separate
key to sign commits, the release key can be made hard to get to.
Imported wallets used to send change back to the "from address".
We keep this behaviour as default.
There has already been an option "Use change addresses" (exposed in GUI),
ignored so far by imported wallets (was only used by HD wallets).
With this change, imported wallets no longer ignore that option, and if set,
they will send change to a random unused imported address, instead of back to "from address".
If all addresses are used, it falls back to sending change back to the "from address".
see: https://github.com/spesmilo/electrum/pull/7330
see: https://github.com/spesmilo/electrum/issues/5353
Re get_change_addresses_for_new_transaction,
"allow_reuse" is a confusing parameter name:
it means whether we allow reusing already used change addresses to send new change to.
However, if the method returns [], we will instead reuse the "from address" and send change there.
So it quite unclear without thinking it through what "allow_reuse" means as it could be either
of the two (and they are ~opposite scenarios).
The new name is long but at least it is clear.
Previously if the wallet did not have a deterministic node id,
the wallet info dialog could say "lightning enabled, non-recoverable channels", but
the "recoverable channels" setting could be toggled and might even say "yes".
* Remove check for sign with privkey in init_cmdline
* Add with_privkey and with_wallet variants of signtransaction command
* Add unit tests for signtransaction_with_privkey and signtransaction_with_wallet commands
This is a regression from 64a931f21e,
which introduced "onchain_channel_backups", and renamed
the old "channel_backups" key to "imported_channel_backups".
The `save_backup` method was not changed to use the new "imported_channel_backups" key,
so the channel backups are in the backup file but they are ignored.
