Set max workers for `retry_and_validate_get_parquet_file_and_size` in `config-parquet-and-info` to 4
I assume the fact that we don't restrict the max number of workers (which results in [32 workers](https://github.com/tqdm/tqdm/blob/master/tqdm/contrib/concurrent.py#L44)* from `tqdm.contrib.concurrent.thread_map` which we use at this step) might result in (likely) OOM for `bigcode/the-stack-v2`. Since there are about 1k parquet files in this dataset.

\+ add logs to see where exactly that happens to support this hypothesis.

*UPD: i'm not sure here because in theory Kubernetes should restrict the max number of accessible cpu's to 8 https://github.com/huggingface/datasets-server/blob/main/chart/env/prod.yaml#L452
But when I monitor in `htop` I see that all cpu's are loaded at this moment. 
Set max workers for `retry_and_validate_get_parquet_file_and_size` in `config-parquet-and-info` to 4: I assume the fact that we don't restrict the max number of workers (which results in [32 workers](https://github.com/tqdm/tqdm/blob/master/tqdm/contrib/concurrent.py#L44)* from `tqdm.contrib.concurrent.thread_map` which we use at this step) might result in (likely) OOM for `bigcode/the-stack-v2`. Since there are about 1k parquet files in this dataset.

\+ add logs to see where exactly that happens to support this hypothesis.

*UPD: i'm not sure here because in theory Kubernetes should restrict the max number of accessible cpu's to 8 https://github.com/huggingface/datasets-server/blob/main/chart/env/prod.yaml#L452
But when I monitor in `htop` I see that all cpu's are loaded at this moment. 