Add a new algorithm for finding the liquidity in a payment path. There
is still a reverse and forward pass, but the forward pass starts at the
limiting step rather than the payment source. This insures the limiting
step is completely consumed rather than potentially leaving a 'dust'
amount in the forward pass.
Each step in a payment is either a book step, a direct step (account to
account step), or an xrp endpoint. Each step in the existing
implementation is a triple, where each element in the triple is either
an account of a book, for a total of eight step types.
Since accounts are considered in pairs, rather than triples, transfer
fees are handled differently. In V1 of payments, in the payment path
A -> gw ->B, if A redeems to gw, and gw issues to B, a transfer fee is
changed. In the new code, a transfer fee is changed even if A issues to
gw.
In some cases multiplying or dividing STAmounts gave incorrect results.
This happens when:
1) The result should be rounded up
2) The STAmount represents a native value (XRP)
3) The rounded up value was less than one drop
In this case, the result was zero, instead of one drop. This could
cause funded offers to be removed as unfunded.
Include the ledger sequence number in fee change transactions to ensure
each such transaction has a unique transaction ID.
We tolerate the absence of a ledger sequence in fee change transactions so
that past fee change transactions remain parseable. Since no live amendment
transactions have yet happened, there is no need to tolerate an absent
ledger sequence there.
With the addition of multisigning there are a variety of reasons
a signature may fail. We now return a more descriptive message
for the reason certain signature checks fail.
The RippleAddress class was used to represent a number of fundamentally
different types: account public keys, account secret keys, node public
keys, node secret keys, seeds and generators.
The class is replaced by the following types:
* PublicKey for account and node public keys
* SecretKey for account and node private keys
* Generator for generating secp256k1 accounts
* Seed for account, node and generator seeds
* A new, unified interface for generating random numbers and
filling buffers supporting any engine that fits the
UniformRandomNumberGenerator concept;
* Automatically seeded replacement for rand using the fast
xorshift+ PRNG engine;
* A CSPRNG engine that can be used with the new framework
when needing to to generate cryptographically secure
randomness.
* Unit test cleanups to work with new engine.
tapENABLE_TESTING is removed from checks, and feature enablement
is the sole method for activating features. Unit tests are updated
to enable required features in the construction of the Env.
Tickets are put on a feature switch instead of a build macro.
* Remove the ability to construct an empty transaction by type, only
to then have to add fields to it. Instead, offer a constructor that
accepts a transaction type and a lambda that can insert fields into
the STTx during construction.
* Remove now obsolete boost::optional transaction ID.
* Expire validations faster based on when we first saw them.
* Never jump to a ledger prior to the latest fully-valid ledger
* Drop validations with signing times too far in the future immediately
Very small payment could fail when STAmount::mulRound underflowed
and returned zero, when it should have rounded up to the smallest
representable value.
