Modify /splits worker
The /splits endpoint is now redundant with the /config-names and the /split-names endpoints and can be computed from them.
One benefit is getting a list of configs and splits, even if some configs are erroneous. See #208 and #701.

We want to keep the /splits endpoint (used by the Hub, for example) but compute it from the other responses. Various options:
1. on every request to /splits, get all the /config-names and /split-names responses for the dataset from the database, and forge the response
2. same as 1., but putting a cache layer
3. precompute the /splits response as soon as possible, and put it in the database. 1. it would still require a worker (not a problem), 2. it should be launched after every update of a /config-names or /split-names for the dataset. Possibly the best option.

Pending questions:
- what should be the format if a /split-names response is an error, while the /config-names response is OK. The current /splits worker would generate an error response, which defeats #208 and #701. Ideally, we want to have a list of configs, with the list of splits, or an error if we cannot get them. But we have to keep backwards compatibility, or change it in the Hub and the other known clients.
- how to manage the transition? Even if the format change, I think that the old format would still be a valid result, and we would replace them at our own pace with the new format.
Modify /splits worker: The /splits endpoint is now redundant with the /config-names and the /split-names endpoints and can be computed from them.
One benefit is getting a list of configs and splits, even if some configs are erroneous. See #208 and #701.

We want to keep the /splits endpoint (used by the Hub, for example) but compute it from the other responses. Various options:
1. on every request to /splits, get all the /config-names and /split-names responses for the dataset from the database, and forge the response
2. same as 1., but putting a cache layer
3. precompute the /splits response as soon as possible, and put it in the database. 1. it would still require a worker (not a problem), 2. it should be launched after every update of a /config-names or /split-names for the dataset. Possibly the best option.

Pending questions:
- what should be the format if a /split-names response is an error, while the /config-names response is OK. The current /splits worker would generate an error response, which defeats #208 and #701. Ideally, we want to have a list of configs, with the list of splits, or an error if we cannot get them. But we have to keep backwards compatibility, or change it in the Hub and the other known clients.
- how to manage the transition? Even if the format change, I think that the old format would still be a valid result, and we would replace them at our own pace with the new format.