this ensures that key order is stable in cases where some ERC20 tokens
are sorted with identical keys which change later
i.e.: Two tokens with erc20:eth:REP keys are sorted based on the order
of reading them from disk. Previously, at most one such key would be
left in data so their mutual order wouldn't matter. Now, one of them can
be deprecated and get a ":deprecated" suffix. Depending on the load
order, this could be the first or the second of them, so the resulting
sort would not be stable.
To fix that, we do key deduplication first and sorting second.
To prevent further problems like this, we also sort glob results.
Ethereum's verify_function takes an actual address as an argument not a
derivation path. So any path validation does not make any sense.
Also, if the verify_recover function raises an exception, it gets
propogated as a DataError (additional fix for #422).
This fixes the problem where the user disconnects a device, connects a
different one, and the library doesn't notice because opening the same
HID path worked fine. (see https://github.com/spesmilo/electrum/issues/4806 )
Previously if an import of a dependent module (usb1, hid) failed, import
of the whole transport module would fail. This was resolved by catching
ImportErrors in the all_transports method.
This had two drawbacks:
- if something other than ImportError happened - e.g., libusb would
raise OSError if it couldn't find libusb.so - all_transports would crash
anyway
- at the same time, if a legitimately needed dependency
(typing_extensions) was missing, this would be masked by the ImportError
handling.
Instead, we unconditionally import the modules, and inside each one,
wrap dependencies in a try-except.
As an added benefit, it is now possible to disable a transport just by
setting SomeTransport.ENABLED = False
move all methods that are still relevant to TrezorClient (originally
BaseClient)
modify ProtocolMixin to be a compatibility shim
modify BaseClient to be a compatibility shim with a proxy to original
actual TrezorClient - this prevents early failures in Electrum for long
enough to show an error message
Only a limited number of messages should be dispatched to handlers
that can be inserted anywhere in the protocol flow. Having a fixed list
of interjecting handlers makes this clearer and prevents hard-to-find
bugs.
