* Add Validations.LedgerSeq and .InitialSeq fields.
* Clean up logging.
* Lower online delete minimum for standalone mode.
* Unit tests of online_delete.
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.
The Journal API is affected. There are two uses for the
Journal::Severity enum:
o It is used to declare a threshold which log messages must meet
in order to be logged.
o It declares the current logging level which will be compared
to the threshold.
Those uses that affect the threshold are now named threshold()
rather than severity() to make the uses easier to distinguish.
Additionally, Journal no longer carries a Severity variable.
All handling of the threshold() is now delegated to the
Journal::Sink.
Sinks are no longer constructed with a default threshold of
kWarning; their threshold must be passed in on construction.
When placing an offer that sells XRP, if the account's balance was
low enough that paying the transaction fee would drop the balance
below the reserve, the transaction should return tecUNFUNDED_OFFER.
The existing implementation returned a tesSUCCESS instead. Although
the net result is the same as far as the transaction's effects are
concerned (the offer is not placed on the books and the transaction
fee is charged) the incorrect result code makes deciphering metadata
difficult.
Add unit test that verifies the new behavior.
* Test whether offers which either already below the reserve (or
would go below during processing) can execute if they cross.
* Test the "Fill or Kill" and "Immediate or Cancel" flags.
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.
