docs: implement multi-tenancy updates

[brad-dow]

With the addition of multi-tenancy support, the Rafiki docs need quite a bit of updating. I've tried to capture all of the changes where multi-tenancy has impacted Rafiki. FIxes #3545

New pages:

• Overview > Concepts > Multi-tenancy - conceptual overview of multi-tenancy through the lens of Rafiki without getting too technical
• Integration > Requirements > Tenants - technical overview of tenants and how to create/update/delete

Updated content:

• Existing sections updated (peers, assets, wallet addresses, webhooks, exchange rates, asset/peer liquidity etc.) to incorporate multi-tenancy considerations, like tenant-specific settings and access
• Rafiki Admin guide reworked with tenant section and new screenshots from top to bottom
• Services pages (auth, backend, frontend) updated as well as environment variable tables to include tenantId among other things
• Backend service page updated with new authentication & authorization section to discuss HTTP signatures
• Local playground updated to include commands to spin up a localenv with multi-tenancy enabled and introducing Cloud Ten mock ASE as the tenant of Cloud 9
• Glossary updated to include "operator" and "tenant"

Still needs work/input:

There are some more areas that need some work that include, but are not limited to, the following:

• Localenv README - architecture diagram and corresponding tables showing URLs needs rework
• Resources > Architecture - diagram here needs rework
• Anything else you see, shout it out!

Required

• Used LinkOut component on external links
• Reviewed Vale errors and made changes where appropriate
• Ran Prettier
• Previewed updates in Netlify
• Received SME and/or peer approval if updates are significant
• Included a "fixes #" comment

Conditional

• Ensured sequence diagrams follow our style guide
• Included code samples where appropriate
• Updated related READMEs

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec ready!

Name	Link
🔨 Latest commit	7f7ac41
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/68e564d992a3190008ddd18c
😎 Deploy Preview	https://deploy-preview-3639--brilliant-pasca-3e80ec.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 41.56
• Iterations/s: 13.87
• Failed Requests: 0.00% (0 of 2499)

📜 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..................: 902 kB 15 kB/s
     data_sent......................: 1.9 MB 32 kB/s
     http_req_blocked...............: avg=7.61µs   min=2.18µs   med=5.21µs  max=875.03µs p(90)=6.37µs   p(95)=6.89µs  
     http_req_connecting............: avg=975ns    min=0s       med=0s      max=836.51µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=95.59ms  min=8.73ms   med=78.2ms  max=471.22ms p(90)=166.45ms p(95)=184.43ms
       { expected_response:true }...: avg=95.59ms  min=8.73ms   med=78.2ms  max=471.22ms p(90)=166.45ms p(95)=184.43ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2499
     http_req_receiving.............: avg=88.77µs  min=23.03µs  med=77.73µs max=1.64ms   p(90)=113.63µs p(95)=142.26µs
     http_req_sending...............: avg=36.69µs  min=9.54µs   med=27.22µs max=3.07ms   p(90)=39.12µs  p(95)=53.5µs  
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s      max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=95.47ms  min=8.43ms   med=78.07ms max=469.87ms p(90)=166.32ms p(95)=184.31ms
     http_reqs......................: 2499   41.55739/s
     iteration_duration.............: avg=288.07ms min=152.45ms med=275.4ms max=975.36ms p(90)=348.33ms p(95)=402.77ms
     iterations.....................: 834    13.869093/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4 

[brad-dow]

Hello @mkurapov , @BlairCurrey , @njlie , @oana-lolea , & @sanducb!

I've completed a first pass on the multi-tenancy documentation updates. For this review, let's focus on technical accuracy only. Multi-tenancy touches a lot of areas, so a comprehensive check would be great to make sure I've captured everything correctly. Please disregard writing mechanics/style/tone for now; we'll address that in the next round of reviews. Thanks!

[BlairCurrey]

• Localenv README - architecture diagram and corresponding tables showing URLs needs rework
• Resources > Architecture - diagram here needs rework

I wouldn't mind if this was addressed outside of this PR. But this got me thinking.

Do we even need the local environment diagram? There are many ways to initialize it and I dont think we should try to depict all of it in one diagram. If we only want to depict 1 I'd assume it would be the default, which the diagram doesn't exactly depict as it currently is. 1 good Rafiki diagram and then the specific implementation details in the docker files makes sense to me. I realize I may be biased as someone whose often in the docker files, but then again, devs are going to be the primary audience for the readme.

[BlairCurrey]

I would mention somewhere that the tenant's (non-operator) credentials (id, secret) need to be communicated to the tenant out-of-band.

That is, the operator will have the uuid and secret after creating but the tenant wont. They need to securely communicate that. Rafiki doesnt do that.

I would mention it at the end of the instructions for the operator to create the tenant and at the beginning of the instructions to set the credentials (operator will use the same as the env vars they set, tenant will use operator provided ones).

Also, nice job on the updates! This was a big one.

[mkurapov]

Priority items before merge:

• The operator must generate its own v4 UUID OPERATOR_TENANT_ID and API_SECRET
• Tenant's (non-operator) credentials (id, secret) need to be communicated to the tenant out-of-band
• Request signing update (docs: implement multi-tenancy updates #3639 (comment))

[brad-dow]

Hey @mkurapov - I think my latest commit passes the "priority items before merge" bar. Can you check some of the technical bits?

Some of the high-level changes are as follows:

• Request signing: All Backend Admin API references now say HMAC SHA-256 with tenant-id header (no “HTTP signatures” wording). Distinguish from Open Payments HTTP Message Signatures and webhook Rafiki-Signature.
• Added UUID v4 requirement for OPERATOR_TENANT_ID, strong API_SECRET
• Tenant credential handoff: Explicit out-of-band delivery of id + apiSecret after creation.
• WALLET_ADDRESS_URL immutability (once set, cannot change)

[mkurapov]

Looking good, a few comments