This is the second release in a row where LLVM has cut a X.0.1 for
everything except Darwin, so I've adjusted its URLs and paths on the
assumption this will continue.
Sapling spend and output max element counts may be safely made
noncontextual because the existing transaction size limit checks
would be violated by transactions containing more than 2^16 such
elements.
`getBalanceZaddr` is modified to take an optional `RawAddress` instead of
a string. This limits it to showing the balance of a single protocol
address, which is fine: `z_getbalance` is the only user of this function,
and we are deprecating that RPC method (replacing it with RPC methods that
can show more detailed information for UAs).
`CWallet::GetNullifiersForAddresses` and `CWallet::IsNote*Change` now use
`RawAddress` because they are generally fed the same addresses as
`GetFilteredNotes`, and in the context of specific notes we need to work
with protocol addresses.
Currently, `libzcash::PaymentAddress` serves two purposes: it represents
the result of parsing a string encoding provided by a user, and it holds
the possible shielded protocol addresses that can be used in transaction
outputs. In order to add support for Unified Addresses, we split these
purposes across two separate types.
We also add two new visitors to enable converting between these types:
- `RecipientForPaymentAddress` returns the "preferred protocol address"
that should be used in transaction outputs, or `std::nullopt` if the
payment address encoding was invalid.
- `GetRawAddresses` returns all protocol addresses contained within the
given payment address, or an empty set if the payment address encoding
was invalid.
For the existing address encodings, the implementations of these are
trivial.
If `valueBalanceSapling` were `INT64_MIN`, the negation would be undefined
behaviour. Also, if `valueBalanceSapling` were a large-magnitude value
then `nValueOut += -valueBalanceSapling;` could overflow, which would be
undefined behaviour.
In practice neither of these cases can happen because `GetValueOut()` is
only called on non-contextually valid transactions, for which
`valueBalanceSapling` will have been checked to be in range.
`GetShieldedValueIn()` is similarly cleaned up for consistency.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>