Aliter: Implement DeliverMax alias in Payment transactions, through autofill method

[ckeshava]

High Level Overview of Change

This is an alternative solution for the DeliverMax alias, inspired from this discussion: #2684 (comment)

Note: Only one of these two PRs must be merged.

Both the PRs seek to achieve the same objectives, albeit through different means.

Context of Change

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)
• Tests (You added tests for code that already exists, or your new feature included in this PR)
• Documentation Updates
• Release

Did you update HISTORY.md?

• Yes
• No, this change does not impact library users

Test Plan

Added unit tests

[ckeshava]

Do you guys have any ideas for complying with lint errors? For instance:

error    Unsafe member access .DeliverMax on an `any` value                                @typescript-eslint/no-unsafe-member-access

error    Unsafe return of type `Promise<any>` from function with return type `Promise<T>`  @typescript-eslint/no-unsafe-return

[ckeshava]

@mvadari Do you have any workarounds for the lint errors? type-erasure does not seem to sit well with the linter.

[mvadari]

@mvadari Do you have any workarounds for the lint errors? type-erasure does not seem to sit well with the linter.

Feel free to disable the linter error for that line.

[ckeshava]

thanks, I've fixed the linter errors and warnings. I didn't realize that I could ignore the errors and get away with it haha

I think it's safe to ignore the linter errors because, a malformed input is sure to through an error in signing or serialization steps.

[ckeshava]

sorry about the forced updates, I had messed up the git history

[khancode]

We should also add integ tests to verify it works for both API versions under packages/xrpl/test/integration/transactions/payment.test.ts

[ckeshava]

Integration tests are set up against rippledv2.2.0-b3 in the current codebase. I tried to execute the integration tests against v1.12.0 (this rippled version contains API v1), but I'm running into some config errors

[ckeshava]

@justinr1234 here is the test case where the ValidationError is caught as expected -- there is not websocket connection to a rippled instance, but it traverses the new code path.

[ckeshava]

this is not an integration test, hence it does not involve any codepaths through connection.ts or other websocket related functions

[pdp2121]

LGTM