MyECLPay's 2nd payment method: the "classical" purchase

[Marc-Andrieu]

Description

Summary

As of now, MyECLPay has only one payment method: the QR Code scanning, involving a seller user who makes the API call.
This PR adds a second payment method: the "classical" purchase, involving only the buyer, who makes the API call themself.

This 2nd payment method is meant to be used by other modules: AMAP, purchases itself, web front-ends indirectly (CdR, ...), etc.

Changes Made

• Aded endpoint to make a purchase at the buyer user's request, with unforgiving business logic
• Refacto stuff in common with the scan payment method: signature verification, TransactionRequestInfo model (the one with the total amount, the IAT, the signature etc), the UsedTransactionRequest table for idempotency (can't be debited twice if retrying),
• New INDIRECT transaction type (because distant, as opposed to DIRECT for scanning which involves a direct seller user). Also the history types has new INDIRECT_GIVEN and INDIRECT_RECEIVED (the direct transaction type is still associated to GIVEN and RECEIVED), I'm not sure of this design however!
• A 20 second expiration: perhaps too short? (the idea: if you have a slow network and ragequit, you won't be debited mysteriously due to some retry in the network)
• Migration and tests

Additional Notes

Differences with the scan payment method:

• No notion of membership check endpoint and bypass: you have to have the membership (if the store's structure requires one)
• The model has no store bool: because the path is /myeclpay/stores/{store_id}/purchase, you can only pay a store by design
• We verify the user performing the request is indeed the owner of the device that signed the transaction request

Classification

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 🔨 Refactor (non-breaking change that neither fixes a bug nor adds a feature)
• 🔧 Infra CI/CD (changes to configs of workflows)
• 💥 BREAKING CHANGE (fix or feature that require a new minimal version of the front-end)
• 😶‍🌫️ No impact for the end-users

Impact & Scope

• Core functionality changes
• Single module changes
• Multiple modules changes
• Database migrations required
• Other: ...

Testing

• 1. Tested this locally
• 2. Added/modified tests that pass the CI (or tested in a downstream fork)
• 3. Tested in a deployed pre-prod
• 0. Untestable (exceptionally), will be tested in prod directly

Documentation

• Updated the docs accordingly :
• " Docstrings
• # Inline comments
• No documentation needed