docs: implement multi-tenancy updates & add versioning

[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	afe3973
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/68f22e36fa00100008507918
😎 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: 44.54
• Iterations/s: 14.85
• Failed Requests: 0.00% (0 of 2678)

📜 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..................: 967 kB 16 kB/s
     data_sent......................: 2.1 MB 34 kB/s
     http_req_blocked...............: avg=5.48µs   min=1.8µs   med=4.82µs   max=253.3µs  p(90)=6.04µs   p(95)=6.41µs  
     http_req_connecting............: avg=282ns    min=0s      med=0s       max=182.39µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=89.18ms  min=6.99ms  med=73.36ms  max=571.93ms p(90)=148.6ms  p(95)=166.26ms
       { expected_response:true }...: avg=89.18ms  min=6.99ms  med=73.36ms  max=571.93ms p(90)=148.6ms  p(95)=166.26ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2678
     http_req_receiving.............: avg=81.88µs  min=25.76µs med=69.94µs  max=1.49ms   p(90)=108.03µs p(95)=140.2µs 
     http_req_sending...............: avg=36.23µs  min=9.33µs  med=25.97µs  max=2.93ms   p(90)=37.68µs  p(95)=53.26µs 
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=89.06ms  min=6.86ms  med=73.26ms  max=571.84ms p(90)=148.46ms p(95)=166.17ms
     http_reqs......................: 2678   44.536118/s
     iteration_duration.............: avg=268.97ms min=181.4ms med=256.08ms max=1.07s    p(90)=315.12ms p(95)=354.66ms
     iterations.....................: 893    14.850916/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 & add versioning #3639 (comment))

[mkurapov]

Looking good, a few comments

[mkurapov]

Suggested change

	You must configure multi‑tenancy by establishing the operator and enabling tenant‑scoped access. Generate a UUID v4 for `OPERATOR_TENANT_ID` and a strong, random `API_SECRET`, create the operator tenant record in the backend service’s Postgres database before startup, and plan a secure out‑of‑band process to deliver each tenant’s `id` and `apiSecret` after creation.
	You must configure multi‑tenancy by establishing the operator and enabling tenant‑scoped access. Generate a UUID v4 for `OPERATOR_TENANT_ID` and a strong, random `API_SECRET`, and plan a secure out‑of‑band process to deliver each tenant’s `id` and `apiSecret` after creation.

Since the tenant record is created automatically

[mkurapov]

Just need to run pnpm format for the checks