Was getting error:
```
>>> import copy
>>> from electrum.simple_config import SimpleConfig
>>> copy.deepcopy(SimpleConfig.EXPERIMENTAL_LN_FORWARD_PAYMENTS)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "...\Python\Python310\lib\copy.py", line 161, in deepcopy
rv = reductor(4)
TypeError: cannot pickle 'ConfigVar' object
```
This is useful in tests/test_lnpeer.py, to deepcopy the GRAPH_DEFINITIONS dict.
A new config API is introduced, and ~all of the codebase is adapted to it.
The old API is kept but mainly only for dynamic usage where its extra flexibility is needed.
Using examples, the old config API looked this:
```
>>> config.get("request_expiry", 86400)
604800
>>> config.set_key("request_expiry", 86400)
>>>
```
The new config API instead:
```
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS
604800
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS = 86400
>>>
```
The old API operated on arbitrary string keys, the new one uses
a static ~enum-like list of variables.
With the new API:
- there is a single centralised list of config variables, as opposed to
these being scattered all over
- no more duplication of default values (in the getters)
- there is now some (minimal for now) type-validation/conversion for
the config values
closes https://github.com/spesmilo/electrum/pull/5640
closes https://github.com/spesmilo/electrum/pull/5649
Note: there is yet a third API added here, for certain niche/abstract use-cases,
where we need a reference to the config variable itself.
It should only be used when needed:
```
>>> var = config.cv.WALLET_PAYREQ_EXPIRY_SECONDS
>>> var
<ConfigVarWithConfig key='request_expiry'>
>>> var.get()
604800
>>> var.set(3600)
>>> var.get_default_value()
86400
>>> var.is_set()
True
>>> var.is_modifiable()
True
```
Change the logging message displayed when the config file can't be
parsed: include the underlying exception text, so that a user who is
attepting to edit the config manually can find and fix any errors.
fixes https://github.com/spesmilo/electrum/issues/7447
Consider this trace for 4.2.0:
```
Traceback (most recent call last):
File "electrum/gui/qt/__init__.py", line 332, in start_new_window
File "electrum/gui/qt/__init__.py", line 363, in _start_wizard_to_select_or_create_wallet
File "electrum/gui/qt/installwizard.py", line 302, in select_storage
File "electrum/util.py", line 504, in get_new_wallet_name
PermissionError: [Errno 1] Operation not permitted: '/Users/admin/Documents/Peach/MS'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "electrum/gui/qt/__init__.py", line 426, in main
File "electrum/gui/qt/__init__.py", line 307, in wrapper
File "electrum/gui/qt/__init__.py", line 349, in start_new_window
File "electrum/util.py", line 504, in get_new_wallet_name
PermissionError: [Errno 1] Operation not permitted: '/Users/admin/Documents/Peach/MS'
```
Note that `get_new_wallet_name` (os.listdir) can raise OSError,
and we were calling that on the main entrypoint codepath without exception-handling.
We were also calling it in the fallback codepath without exception-handling.
i.e. the GUI errored out on every startup for affected users, and without CLI usage
it was not possible to recover.
config.mempool_fees is now [] if server claims mempool is ~empty,
and None if no valid histogram has been received from server.
(previously it used to be [] in both cases)
- print the test name before each test
- start only needed agents (alice, bob, carol)
- set settle_delay using setconfig instead of restarting daemon
- test the watchtower ctn in test_watchtower
By default, Electrum saves the last opened wallet's path as well as
recently opened wallets.
This can be damaging to plausible deniability.
Now it's possible to run Electrum with `--forgetconfig` to not
write to the config at all, which includes the wallet paths.
The few other cases that used SimpleConfig.get_instance() now
either get passed a config instance, or they try to get a reference
to something else that has a reference to a config.
(see lnsweep, qt/qrcodewidget, qt/qrtextedit)
- commands are async
- the asyncio loop is started and stopped from the main script
- the daemon's main loop runs in the main thread
- use jsonrpcserver and jsonrpcclient instead of jsonrpclib
