feat(card-service): handle payment cancelled & funded events

[sanducb]

Changes proposed in this pull request

This PR handles the outgoing_payment.funded and outgoing_payment.cancelled events that we are sending from the backend to the card service (RAF-1156)

Context

Closes RAF-1168

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: 44.54
• Iterations/s: 14.85
• Failed Requests: 0.00% (0 of 2681)

📜 Logs

> [email protected] 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..................: 968 kB 16 kB/s
     data_sent......................: 2.1 MB 34 kB/s
     http_req_blocked...............: avg=6.5µs    min=2.25µs  med=4.96µs   max=499.91µs p(90)=6.11µs   p(95)=6.54µs  
     http_req_connecting............: avg=479ns    min=0s      med=0s       max=379.85µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=89.21ms  min=6.72ms  med=71.92ms  max=607.31ms p(90)=155.69ms p(95)=176.81ms
       { expected_response:true }...: avg=89.21ms  min=6.72ms  med=71.92ms  max=607.31ms p(90)=155.69ms p(95)=176.81ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2681
     http_req_receiving.............: avg=84.19µs  min=23.69µs med=72.87µs  max=2.22ms   p(90)=109.29µs p(95)=142.84µs
     http_req_sending...............: avg=33.8µs   min=9.42µs  med=26.57µs  max=2.45ms   p(90)=38.07µs  p(95)=51.27µs 
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=89.09ms  min=6.49ms  med=71.67ms  max=607.24ms p(90)=155.6ms  p(95)=176.7ms 
     http_reqs......................: 2681   44.535754/s
     iteration_duration.............: avg=269.08ms min=156.2ms med=255.07ms max=1.23s    p(90)=333.49ms p(95)=361.11ms
     iterations.....................: 894    14.850789/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4 

[mkurapov]

This isn't related to this PR, but for both card-service and POS service but most of the logic should live in the corresponding service.ts, as otherwise, we are coupling the "application layer" with our actual domain code. If made this, say, a GraphQL API, we shouldn't need to change any of the domain logic about how we are handling events and making the payment work.

In any case, let's get this working and we can do all kinds of polishing later :)

[sanducb]

Created RAF_1174 for that 👍

[mkurapov]

do we need void?