Change order of checks in amm_info

[Bronek]

High Level Overview of Change

Checking if account is well-formed currently happens before the check if asset , asset2 and amm_account are supplied, which results in an unexpected error messages if any of the fields is malformed. Swap the order of checks, so validity of fields is verified first. Since this is a breaking change, retain the existing behaviour if (apiVersion < 3) and add identical check, but after checks of assets and accounts, if (apiVersion >= 3). Also add unit tests to demonstrate the old and new behaviour.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Performance (increase or change in throughput and/or latency)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

Before: sending an invalid account or asset to amm_info RPC method while other parameters are not set as expected would result in rpcINVALID_PARAMS error. This behaviour is retained in API version 2

After: sending an invalid account or asset to amm_info RPC method while other parameters are not set as expected will result in rpcISSUE_MALFORMED or rpcACT_MALFORMED error. This behaviour is new in API version 3

This resolves XRPLF/clio#1157

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.3%. Comparing base (223e6c7) to head (50e2fae).

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #4924     +/-   ##
=========================================
- Coverage     71.3%   71.3%   -0.0%     
=========================================
  Files          796     796             
  Lines        66981   66987      +6     
  Branches     10871   10887     +16     
=========================================
- Hits         47774   47763     -11     
- Misses       19207   19224     +17     

Files	Coverage Δ
src/ripple/rpc/handlers/AMMInfo.cpp	92.0% <100.0%> (+0.4%)	⬆️

... and 8 files with indirect coverage changes

[godexsoft]

LGTM 👍

[gregtatcam]

👍 LGTM

[Bronek]

this is good to merge - note it preserves the current behaviour in API version 2 and adds a test for it.

[godexsoft]

Is this going to be merged soon?

[seelabs]

@godexsoft Yes, it should be merged today.

[godexsoft]

@Bronek this still requires [beta_rpc_api] to be set to 1 in config. Don't we want this to be enabled by default as the maximum allowed version yet? What's the plan for the switch if any?

[ximinez]

this still requires [beta_rpc_api] to be set to 1 in config. Don't we want this to be enabled by default as the maximum allowed version yet? What's the plan for the switch if any?

We never want [beta_rpc_api] to be 1 by default. If we want to declare a particular version of the API as done, then we make that version supported by increasing apiMaximumSupportedVersion and then we open up a "new" beta version by incrementing apiBetaVersion. apiBetaVersion should probably always be one more than apiMaximumSupportedVersion.

[godexsoft]

this still requires [beta_rpc_api] to be set to 1 in config. Don't we want this to be enabled by default as the maximum allowed version yet? What's the plan for the switch if any?

We never want [beta_rpc_api] to be 1 by default. If we want to declare a particular version of the API as done, then we make that version supported by increasing apiMaximumSupportedVersion and then we open up a "new" beta version by incrementing apiBetaVersion. apiBetaVersion should probably always be one more than apiMaximumSupportedVersion.

I did not mean to have the beta enabled by default, that would be silly. I mean to have v3 as the new maximum version. I guess my wording was a little off 🔢
In Clio we will start treating v3 as the maximum (but not default) version in one of the next releases just so we can forward to rippled with v3. But turns out v3 is still in beta so this fix here can't be used unless the operator enables beta or rippled moves on to v3 as the new allowed max version to request.