Add The Federation Layer

[Reckless-Satoshi]

follow up of #380. This PR squashes and rebases over main the-federation-layer branch
All API pre-requisites are already merged in Main. This PR contains only frontend changes

What does this PR do?

This PR brings to main the experimental fork The Federation Layer. We will keep it open as a draft for some time to track progress. We will certainly keep it away from main until well tested with a bunch of Testnet voluntary coordinators.

For context read the Issue where the RoboSats Federation concept was introduced #228

Tasks towards RoboSats Federation Minimum Viable Product:

Frontend:

• Read from static/federation.json the list of RoboSats coordinators and their .onion addresses.
• Build Coordinator Dialog with a profile of each coordinator. Optionally, make it cool and add coordinator badges.
• Build Coordinator table (keep it in the Settings tab)
• Refactor Stats dialogs to show aggregated stats for all active coordinators (volume, premium, etc).
• Create Context high level functions and abstractions of the federation.
• Book page requests all orders from all coordinators. Shows each row on coordinator's color as well as the coordinator logo. Book page allows for filtering by Federation member.
• If a user clicks on the order of another coordinator, it should trigger an api/usergen/ request (so that Robot / Avatar / Token hash / PGP pubkey and encPrivKey exists as well on the coordinator's database). EDIT: new middleware will generate robots in the fly if auth token (SHA256(robot_token)) does not exist. New endpoint "Robot" to fetch existing robot nickname, pubkey, etc.
• Everything else in the trade pipeline remains the same. However the /order/ API requests will be made to that order's coordinator .onion address.
• Each coordinator, on its hosted frontend should be able to opt-in and out of showing other coordinators orders. They can do so by editing the static file they host in static/federation.json.
• Use paths for each coordinator. E.g. ...robosats.onion/order/coordinator_shortname/21
• Add a "select host" dropdown in the MakerForm
• Add a new Setting "Number of active coordinators" to select how many coordinators to use at once. Default to 5. Users can increase them at the cost of UI performance.
• At startup coordinators will be selected ranked 1 to N, the rank will be probabilistically linked to the devfund donation (%) of the coordinator. The top K (default 5) will be selected. Orders in the order book will be sorted by coordinator rank by default. This is the only patron perk so far designed to reward those coordinators contributing to RoboSats development.
• If selfhosted, use the same "local" endpoint for every coordinator, yet a different path using the coordinator shortname. E.g. ".../api/coordinator_shortname/order/...".On nodeapp, spawan a socat bridge for each Coordinator Onion address and write nginx config to proxy each API subpath to the coordinator onion endpoint.
• Optional - Low priority On the coordinator table, add tools for users to delete/add coordinators using a form (issue: these are forgotten in browsers that do not keep local storage after restart. This will work just fine on Android app).
• Optional - Needs research At the end of a trade, the user rates the coordinator (instead of "What do you think of RoboSats?"). The order ID, rating and coordinator alias is sent to every Federation member. The ratings will help keep coordinators informed about their own performance and other federation members performance. It will allow for sorting access to coordinator addresses in the docs / github / frontends according to some non-arbitrary criteria.

Backend:

• Allow CORS. Let other origins make calls to coordinator API.
• Upgrade authentication. Replace SessionID + CSRF token for only robot hash token on every authenticated request. Implement middleware that creates user+profile+avatar entries on first authenticated request with a robot token hash not seen before.
• Deprecate /user/ POST.
• Anyone with the hash of a robot token could send authenticated requests (e.g, another coordinator could MITM attack a user on another coordinator). Solution: robot submits his pubkey on first authenticated requests, then every next requests must be pgp signed?
• Delete current rewards program (hard to fit on a multi-coordinator set up. There are ways, but this is to be explored in the future).
• Implement compute_trade_proceeds() on each trade finished. Implement Keysend feature for Dev donations.
• Limit Coordinator devfund donation to 49% of trade proceeds.
• Optional - Needs research coordinators backend could periodically fetch stats from other coordinators and "keep them in check". E.g. a coordinator might not want to show in its frontend orders of Federation members whose LN node is down, whose trade fee is very large, not contributing Sats to the dev fund, etc.

Other:

• Write up FEDERATION.md base guide/ruleset document.
• Build and release docker-compose orchestration.
• Build and release kubernetes RoboSats orchestration.

[Reckless-Satoshi]

Closing, follow up on v0.6.0 PR #922