…igrations

zcash_client_sqlite: Fix migration DAG edges

release zcash_client_sqlite version 0.11.1

…utChangeStrategy`

doc comments more accurate concerning the choice of output pool.

Signed-off-by: Daira-Emma Hopwood <[email protected]>

These operations are unused, and block heights form a vector space,
not a monoid.

zcash_client_sqlite: Add missing test of `utxos_to_txos` migration.

zcash_protocol: Remove impl {Add, Sub} for BlockHeight

zcash_protocol: Set the public testnet activation height for NU6

Release zcash_protocol version 0.3.0

Release zcash_address version 0.5.0

Release zcash_primitives version 0.17.0

release zcash_proofs version 0.17.0

In contrast to the implementation of `Sub<BlockHeight> for BlockHeight`
that was removed in version `0.3.0`, a saturating subtraction for block
heights having a return type of `u32` makes sense for `BlockHeight`.
Subtracting one block height from another yields the delta between them.

Other block height addition and subtraction operations have been made
saturating, removing panics and the possibility of overflow.

The `FALSE` constant was introduced in sqlite version 3.23.0,
but Android does not support this version of sqlite until API
level 30; we support back to Android API 27 so we have to use
`0` as the constant for `FALSE` instead.

Add correct `BlockHeight` subtraction & remove panics.

…ng_key`

zcash_keys: Add `decode_extfvk_with_network`

The `reserve_until` method for generating ephemeral addresses is used in
database migrations, but it makes no sense to use this in the case that
the UFVK for an account contains no transparent component; such accounts
can never be used to make ZIP 320 spends.

Support older sqlite versions.

…ount` trait.

…dor` for testing.

… moved to `zcash_client_backend`

…from TestState

…_client_sqlite`

…t_sqlite`

…t_sqlite`

…y-doc

Make the `{fixed,standard,zip317}::SingleOutputChangeStrategy` doc comments more accurate concerning the choice of output pool

…st from `zcash_client_sqlite`

zcash_client_sqlite: Do not require a transparent key for migrations.

Generalize the `zcash_client_sqlite` test framework and extract it to `zcash_client_backend`

We already depend on `rustls` and `webpki-roots` for `tor::http`, but
`tonic` has its own feature flag that needs to be enabled for equivalent
support in `tor::grpc`. We didn't need that feature flag enabled for the
`proto::service::compact_tx_streamer_client` module because those
constructors take a `D: TryInto<tonic::transport::Endpoint>`, which
abstracts over TLS and leaves it up to the caller. By constrast, in
`tor::grpc` we need to construct the `Endpoint` manually from a `Uri`
and then configure TLS ourselves.

devtools: Detect more key formats with `zcash-inspect`

zcb::sync: Refresh UTXOs at the start of each scanning cycle

This reduces the feature-flag-related `WalletRead` breakage for crate
users, and gives us a place to expose even more internal Data Access API
implementation details for general testing purposes.

Addresses review comments from #1530.

zip321: Add missing `test-dependencies` feature configuration.

…_progress`

After splitting recover progress out from scan progress, the
overestimation of the chain tip tree size became much more noticeable.
We now extrapolate from the most recent known "notes per block" rate.

…ests

The wrong subtree was being completed, which didn't matter before but
does now that scan progress is extrapolated.

zcash_client_backend: Post-merge cleanups to test framework extraction

Improve progress representation in `WalletSummary`

…am builds.

zcash_client_sqlite: Fix bad `WalletTest` import that breaks downstream builds.

Co-authored-by: Jack Grigg <[email protected]>

…_backend`

Co-authored-by: Willem Olding <[email protected]>

Now that these are in a separate trait, we can just require them for all
downstreams, in order to make them usable in all tests.

Move remaining pool tests from `zcash_client_sqlite` to `zcash_client_backend`

Closes #1538.

Closes #1525.