Refactor Idempotency logic to reduce boilerplate and increase code readability

[peterbroadhurst]

See detailed discussion in #1406

Suggested work

• Combine txHelper utility into operations manager
  • Transactions are really grouping constructs of operations, and tracking the events for async completion
  • There is weirdness that the operations helpers do not have direct access to the idempotencyKey
  • There is a lot of boilerplate in other packages, joining together txHandler and operations functions
• Merge the SubmitNewTransaction and ResubmitOperations functions. Return options are:
  • There is no idempotency key, here's a shiny new TX
  • We've never stored a TX for this idempotency key, here's a shiny new TX
  • TX already existed for idempotency key all done now - please return without error to the user
  • TX was stored, but no operations were stored - here's the existing transaction ID
  • All operations in the TX already reached Pending (or later), 409 to your user
  • Something else went wrong
• (Separable) Update idempotency input handling to reject re-submit with different inputs
  • Scenario:
    1. Submit with input1 and idem1, and get to a point of Initialized operations
    2. Encounter failure that is not handled via internal retry and returns an error to you
    3. Re-submit the API call, but this time with input2 and idem1
    4. Internally FF Core already stored the operations, so re-submits them with input1 (not input2)
    5. Transaction completes with input1 - we ignored the input2 you provided
  • Improved behavior:
    • Return an error stating that input2 is not the same as input1
    • Requires per-input handling to detect the operation inputs are the same or not

[Chengxuan]

@peterbroadhurst

All operations in the TX already reached Pending (or later), 409 to your user

Should this be true for operation requests that have identical payload with what's recorded for a given idempotency key?