`NoteValue - NoteValue` is always guaranteed to produce a valid
`ValueSum`, so we make that infallible and introduce a new helper method
`ValueSum::magnitude_sign` that we use for circuit synthesis.
The `Bundle` struct is variable in size and requires allocations, but
`Action` is not. This split will make it cleaner to disable the bundle
logic for no-std support.
We removed this in zcash/orchard#267 as it did not need to be part of
the public API, but we do still need a way to convert the user-defined
valueBalance type into a `ValueSum` when constructing `bvk`, and this
method is preferable to exposing the `ValueSum` internals.
There is no reason for crate users to be constructing `ValueSum`
directly. We no longer use it to represent `valueBalanceOrchard`,
instead requiring the user to specify their own type.
There was push-back on having this crate require these traits, due to the
additional complexity within this crate. My rationale for including them
was to make it simpler to reason about what is responsible for enforcing
chain-specific constraints, and to reduce duplication (by enabling the
wrapping chain implementation to use type definitions and leverage all
built-in behaviour, instead of newtypes and needing to add a bunch of
wrapping logic and boilerplate, some of which would encode chain-specific
logic).
We'll try working within the requirement that this crate enforces minimal
base constraints and hard-codes any constants, and then have the wrapping
chain provide encoding prefixes and additional value constraints where
necessary.