Make XRPFees a non-breaking API change

[intelliot]

Issue Description

#4247 introduces an amendment, featureXRPFees (XRPFees for short), and causes some breaking API changes.

The motivations for the amendment:

• The fee code is unnecessarily complex due to arcane concepts like "fee units" and "reference transactions" - represented as integers of various widths. A lot of effort is expended to keep all that straight and prevent developers from doing the wrong thing.
• Fee units are hard-coded to 10 and the "reference transaction" fee is also 10, so there is an opportunity to reduce complexity: replace "fee units" with XRPAmount for all fees. Scaling/adjusting of fees can operate directly on XRPAmount objects instead.

XRPFees converts all representations of fees in the code, ledger, and protocol into XRPAmounts.

Currently, in the FeeSettings singleton object, BaseFee is serialized as hexadecimal; ReferenceFeeUnits, ReserveBase, ReserveIncrement are serialized as integers (when they would make more sense as strings because they are XRP amounts).

With XRPFees, the replacement fields are named BaseFeeDrops, ReserveBaseDrops, and ReserveIncrementDrops, and they are all XRP amounts serialized as strings.

It appears that there are likely impacts to server_info, SetFee (transaction type) txs and Subscription messages for the ledger and validations stream.

Expected Result

Ideally, gain the benefits of XRPFees without the downside of breaking existing API consumers + client libraries.

Actual Result

Some field names and types have changed in the APIs, which would break existing integrations and client library versions.

1. Consider changing the API back to undo any breaking changes that XRPFees: Fee setting and handling improvements #4247 can cause.
2. If there are case(s) where it really makes sense to break the API (i.e. it is impossible or infeasible to support existing clients), clearly document the change and offer a straightforward migration path for existing users.

• @ximinez thinks it may be worth changing the APIs to avoid breaking changes.

Contexts

• Direct rippled API consumers (WebSocket, HTTP JSON-RPC)
• Client libraries (xrpl.js, xrpl-py, xrpl4j)

Related

• Support featureXRPFees amendment xrpl.js#2219

[justinr1234]

thinks it may be worth changing the APIs to avoid breaking changes.

changing how?

[intelliot]

Ideally, the PR and the amendment would not affect any values returned by the API, so client libraries and other integrations don't need to update.

In cases where we do make a change, it would ideally be additive; i.e. add a new field with the nicely-formatted values. We can mark/document some existing fields as deprecated. Then, in 1-2 years, we remove them.

In cases where we make a breaking change today (i.e. an existing field goes away or its value changes), it should be very deliberate and necessary. I don't think that's the case here, where the PR and amendment are purely "cleanup" - it doesn't address any specific user feedback or problems, and it doesn't add any new functionality.

[ckniffen]

I was incorrect in thinking this amendment changed server_info. While fields were updated in many places three did not change even though all three fields (base_fee_xrp, reserve_base_xrp, reserve_inc_xrp) use xrp decimal formats instead of drops.

https://github.com/ximinez/rippled/blob/e7a9e66148c7b4de57b0140d779d757d391e52b0/src/ripple/app/misc/NetworkOPs.cpp#L2596-L2599