Feature Request: endpoint for Federated Directory Services. (federation.json replacement)

[AleziaKurdis]

Currently the "Places" app is getting the list of the Federated Directory Servers from a static file: "federation.json" (local to the app, in the interface installation folder). Overte\scripts\system\places\federation.json

This was a temporary solution that is far to be ideal when the list of the Federated Directory Servers need to be changed.
The original idea was to get that list directly from the Directory Servers in use by Interface. (Which was going to happen one day, when the federation functionality would be added.)

The minimal advantage to get that list from the server, is to not have to publish a new version of interface just to update federation list. And not have to ask to all the user base to proceed to an update.

So the Feature Request, is the following:
Implement a new endpoint, probably under a new Federation API
maybe: GET /api/v1/federation
that would allow the Places app. to get the information from the server.

This could be done in iterative phases.

PHASE 1: Static Data
Expose by this end point the content of a static "federation.json" file that would be stored on the "Directory Server" files.
(this file could be updated manually for now.)

Here is the current structure of this file in the places app:
[
{"node": "https://metaverse.vircadia.com/live"},
{"node": "https://mv.overte.org/server"}
]

PHASE 2: Federation data
When the "federation functionalities" will be added to deal with other "Directory Servers", then the content exposed by that same endpoint could be fed by those "federation functionalities".
We could, by the same time, enhance the exported data to include additional fields, pumped from the Directory Servers, like: "Name", "Description", "picture/icon/flag/banner".

PHASE 3: Larger scale functionalities.
Eventually, it could also include a flat list of places with their url (but not containing heartbeated data like "status" and "number of people").
That flat list could be optionally requested (using any parameter in the request), not by default, to not generate too fat payload to read by the Places app. But that list could be used for "federation wide search engin" to find a specific place and know under which Dir. Server it is located.