Let users join federated training mid session

[JulienVig]

Fixes the federated case of #718

• Have server store the last aggregated model and send it back to participants joining late, or that have fallen behind
• Participants notify server when disconnecting from a task
• Implement a "waiting room" to have at least 2 participants before starting a federated training
• Handle the case when a user ends up alone during in a training session (all the others either stopped or already finished). This user could pause their training and wait until someone else joins
• Handle receiving an invalid server update. Currently, a client waits for a single server update per round. If it receives an old or invalid server updates, the client drops it and skips to the next round. However, the update may simply be delayed. Should the client skip to the next round or wait for another potential update?
• Display the current status in the trainingboard, especially when waiting for new participants.

Refactoring:

• Split server/router into routes and controllers as commonly done in Express. routes setup the router API and controllers handle the actual federated and decentralized logic (via initTask and handle)
• Renamed some files into more explicit names imo (e.g. client/client.ts, client/federated_client.ts, client/decentralized_client.ts)
• Renamed 'feai' and 'deai' occurrences (e.g. server API) into 'federated' and 'decentralized'
• Renamed the TasksAndModels object to TaskInitializer and added doc

[martinjaggi]

BTW for delayed updates during training, the easiest way (and algorithmically valid) is to define a maximum threshold delay, so a time delta (in number of steps/rounds): if an update arrives which was computed based on a model older than this delta, the update is dropped. otherwise it's included.

the aggregation is simply triggered once the number of present valid update candidates (buffer size) is sufficient (this part is already implemented).

that would work well both in decentralized and federated

[JulienVig]

Yes! This should already be implemented, although current defaults always set the time delta to 0. We can probably increase the cutoff to 1 or 2.

[JulienVig]

Sorry for the ugly commit history I had to debug a test case that failed only in the github actions but passed locally.
FYI it was because of network delay letting a client send its contribution before they received the server message to wait for more participants (which should prevent them from sending their contribution). I've solved it by letting the server accept contributions even when below the minimum number of participants but preventing the aggregation until above the threshold.

[tharvik]

wouhou, great work, that's a very neat fix for an important feature. thanks for tests also, very useful to avoid breaking subtle status changes 🎉

a few beautifulization comments, nothing really important

[martinjaggi]

impressive work, big thanks!