Change nomenclature of processing steps
Until now, every public endpoint (ie /splits) was associated with one job and one type of cache entry. But that’s no more the case:

- the response can be computed using two concurrent methods (streaming vs normal, for example), and the first successful response is returned
- the response can be computed at config level (/split-names) then aggregated at dataset level

It’s the occasion to rethink a bit the name of the steps, job types and cache kinds.

For now, every processing step has only one associated job type and cache kind, so we use the same for these three. But it’s no more related to the public API endpoint.

- First change: remove the initial slash (`/step` → `step`)
- Second change: to make it easier to think about, we can include the “level” at which the response is computed in the name of the step (`step` → `dataset-step`)

With these rules, after renaming and implementing some pending issues (https://github.com/huggingface/datasets-server/issues/735) we would end with the following set of processing steps and public endpoints:



Public endpoint | Dataset-level steps | Config-level steps | Split-level steps
-- | -- | -- | --
  | `dataset-config-names` |   |  
`/splits` | `dataset-split-names` | `config-split-names-from-streaming`, `config-split-names-from-dataset-info` |  |  
`/first-rows` |   |   | `split-first-rows-from-streaming`, `split-first-rows-from-parquet` |   |   |  
  |   | `config-parquet-and-dataset-info` |  
`/parquet` | `dataset-parquet` | `config-parquet` |  
`/dataset-info` | `dataset-dataset-info` | `config-dataset-info` |  
`/sizes` | `dataset-sizes` | `config-sizes` |  


<p>Also: every cached response would be accessible through: <code>/admin/cache/[step name]</code>, e.g. <code>/admin/cache/config-parquet-and-dataset-info?dataset=x&amp;config=y</code></p>

Change nomenclature of processing steps: Until now, every public endpoint (ie /splits) was associated with one job and one type of cache entry. But that’s no more the case:

- the response can be computed using two concurrent methods (streaming vs normal, for example), and the first successful response is returned
- the response can be computed at config level (/split-names) then aggregated at dataset level

It’s the occasion to rethink a bit the name of the steps, job types and cache kinds.

For now, every processing step has only one associated job type and cache kind, so we use the same for these three. But it’s no more related to the public API endpoint.

- First change: remove the initial slash (`/step` → `step`)
- Second change: to make it easier to think about, we can include the “level” at which the response is computed in the name of the step (`step` → `dataset-step`)

With these rules, after renaming and implementing some pending issues (https://github.com/huggingface/datasets-server/issues/735) we would end with the following set of processing steps and public endpoints:



Public endpoint | Dataset-level steps | Config-level steps | Split-level steps
-- | -- | -- | --
  | `dataset-config-names` |   |  
`/splits` | `dataset-split-names` | `config-split-names-from-streaming`, `config-split-names-from-dataset-info` |  |  
`/first-rows` |   |   | `split-first-rows-from-streaming`, `split-first-rows-from-parquet` |   |   |  
  |   | `config-parquet-and-dataset-info` |  
`/parquet` | `dataset-parquet` | `config-parquet` |  
`/dataset-info` | `dataset-dataset-info` | `config-dataset-info` |  
`/sizes` | `dataset-sizes` | `config-sizes` |  


<p>Also: every cached response would be accessible through: <code>/admin/cache/[step name]</code>, e.g. <code>/admin/cache/config-parquet-and-dataset-info?dataset=x&amp;config=y</code></p>
