feat(backend): add handlePartialPayment for incoming payments

[njlie]

Changes proposed in this pull request

• Adds a handlePartialPayment service call to the incoming payment service, to be called when encrypted data is transmitted through an ILP stream.

Context

Fixes RAF-1183 and fixes RAF-1184.

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Make sure that all checks pass
• Bruno collection updated (if necessary)
• Documentation issue created with user-docs label (if necessary)
• OpenAPI specs updated (if necessary)

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 40.73
• Iterations/s: 13.58
• Failed Requests: 0.00% (0 of 2450)

📜 Logs

> performance@1.0.0 run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test "-k" "-q" "--vus" "4" "--duration" "1m"

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 884 kB 15 kB/s
     data_sent......................: 1.9 MB 31 kB/s
     http_req_blocked...............: avg=6.94µs   min=1.76µs   med=5.57µs   max=705.38µs p(90)=6.69µs   p(95)=7.27µs  
     http_req_connecting............: avg=657ns    min=0s       med=0s       max=569.82µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=97.52ms  min=6.58ms   med=79.82ms  max=559.03ms p(90)=168.09ms p(95)=192.7ms 
       { expected_response:true }...: avg=97.52ms  min=6.58ms   med=79.82ms  max=559.03ms p(90)=168.09ms p(95)=192.7ms 
     http_req_failed................: 0.00%  ✓ 0         ✗ 2450
     http_req_receiving.............: avg=98.19µs  min=28.4µs   med=83.48µs  max=2.41ms   p(90)=123.14µs p(95)=155.31µs
     http_req_sending...............: avg=38.62µs  min=9.87µs   med=29.06µs  max=6.15ms   p(90)=42.05µs  p(95)=55.18µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=97.39ms  min=6.44ms   med=79.72ms  max=558.91ms p(90)=167.97ms p(95)=192.59ms
     http_reqs......................: 2450   40.733588/s
     iteration_duration.............: avg=294.14ms min=186.96ms med=272.53ms max=1.09s    p(90)=370.62ms p(95)=397.38ms
     iterations.....................: 817    13.583405/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4 

[mkurapov]

Looks good, just a few comments

[mkurapov]

Suggested change

	dataToTransmit: acc.name

Since we have it already anyway

[mkurapov]

Here, we need to add a new property to the data that specifies the amount that was only sent in the "partial" payment, so the receiving ASE can make a decision whether to action it or not. The receivedAmount should remain unchanged, ie, it will include the cumulative amount received thus far for the incoming payment.

I will encapsulate this in a separate issue.

[mkurapov]

If we keep the DB encryption secret as optional, this can just be: "Data to transmit to the recipient during the payment"

[mkurapov]

I think instead of this, we can just assert that depositSpy was called with dataToTransmit (since the resolver doesn't really need to know about how it gets used in the method itself)

[mkurapov]

Do you think the encryption should be an optional feature? I think this might be a good call, as it allows the integrator to decide whether they want it or not.