fix: bunch of fixes on RPC

[Kassaking7]

High Level Overview of Change

Fix account_objects(sponsored=...) misattributes object-level fields

Fix simulate underprices sponsor-multisigned transactions

Fix simulate RPC Node Crash via Malformed SponsorSignature Field

Context of Change

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)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.2%. Comparing base (f650d52) to head (a457c4b).
⚠️ Report is 37 commits behind head on xrplf/sponsor.

Additional details and impacted files

@@               Coverage Diff               @@
##           xrplf/sponsor   #7557     +/-   ##
===============================================
- Coverage           82.3%   82.2%   -0.1%     
===============================================
  Files               1018    1016      -2     
  Lines              78267   78413    +146     
  Branches            8972    9016     +44     
===============================================
+ Hits               64381   64446     +65     
- Misses             13877   13958     +81     
  Partials               9       9             

Files with missing lines	Coverage Δ
src/xrpld/rpc/handlers/account/AccountObjects.cpp	95.0% <100.0%> (+0.3%)	⬆️
src/xrpld/rpc/handlers/transaction/Simulate.cpp	100.0% <100.0%> (ø)

... and 26 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mvadari]

While you're here, can you change this to a non-optional bool that defaults to false?

[yinyiqian1]

I understand this method is used to mimic a Payment’s account-creation behavior during pathfinding, because pathfinding executes before the actual payment creates the destination account. Mocking the newly created destination account so RippleCalc can account for the sponsor resolves the issue. (although looks hacky)

My concern is:

is it worth adding this in path finding just to resolve a very low-impact issue: Payment execution allows tfSponsorCreatedAccount to create a new destination account with a 1-drop XRP delivery because the sponsor covers the reserve, but ripple_path_find still applies the old unsponsored rule and rejects below-reserve payments to nonexistent destinations as dstAmtMalformed.

Since we decided not to consider sponsor in other low-impact edge cases, for example, we do not consider the free first 2 reserves if it is sponsored, do we want to consider it in this case?

@mvadari