because now we are not simply copying the coins.json file
but building it from several.
For future-proofness, it's simply safer to include all of trezor-common.
This helps when you try to build python-trezor from a subdirectory
of trezor-core, for whatever reason.
(For instance, when you run 'pipenv install' in trezor-core, and also
happen to have protobuf build tools available in the outside environment)
We can now selectively runxfail certain tests. This is useful for
accepting PRs into trezor-core:
1. trezor-core is going to get a pytest.ini that sets xfail_strict.
That means that if an `xfail`ed test actually passes, that will
break the test suite. So it will be visible when we implement
a feature for which tests exist.
2. To allow PRs to pass the test suite without touching python-trezor
directly, we add a new pytest.ini option: run_xfail.
This adds a list of markers which will ignore `xfail`.
So:
2.1 First, the python-trezor PR marks the tests with the name
of the feature. This commit already does that: Lisk tests
are marked `@pytest.mark.lisk`, NEMs are `@pytest.mark.nem`,
etc.
The tests will be also marked with `xfail`, because the
feature is not in core yet.
2.2 Then, the trezor-core PR implements the feature, which makes
the `xfail`ed tests pass. That breaks the test suite.
2.3 To fix the test suite, the core PR also adds a `run_xfail`
to `pytest.ini`: `run_xfail = lisk`.
(it can take a list: `run_xfail = lisk nem stellar`)
That will make the test suite behave as if the tests are not
`xfail`ed. If the feature is implemented correctly, the tests
will pass.
2.4 When the PR is accepted to core, the next step should be
a PR to python-trezor that removes the `xfail`s. After that,
we should also remove the `run_xfail` option, just to be tidy.
ed25519raw is moved back to trezorlib
ed25519cosi is renamed to cosi, and has a couple more functions,
with the expectation that TrezorClient.cosi_* methods will move there.
Also most code shouldn't need ed25519raw for anything, so it might get
renamed to "_ed25519" to indicate that it's a private implementation.
For now, I added a "verify" method to cosi, so that you don't need to
call into ed25519raw.checkvalid. But trezor-core's keyctl is also
using ed25519raw.publickey. I'm not sure if that's worth replicating
in cosi, or whether to just leave it be, so I'm leaving it be for now.
Importantly, new function "sign_with_privkey" does that math thing that
was part of the selftest and is also explicitly listed in keyctl.
(it's called sign_with_privkey because I expect to have a "sign" method
here that calls into Trezor)
