Wait for writing in distributed metrics
I agree this fix the problem for the CI where the files are always created in a new and clean temporary directory.

However, in a general setting of a succession of fast distributed operation, the files could already exist from previous metrics runs but one process may still finish before another has even started in which case it would mix results from separate operations.

I feel like the most robust way to solve this is to setup a rendez-vous on the first time we write on files and where each process will test and only finish its operation when it cannot acquire a lock on all the other processes (meaning they all have started).

What do you think? What do you think of this @thomwolf  ? I check all the locks before finalizing Ok on my side @lhoestq (cannot add you as a reviewer) The test doesn't pass if I add:
```python
            import time
            if self.process_id == 1:
                time.sleep(0.5)
```
right before `self.add_batch` in `Metric.compute`.

I'm investigating why it doesn't work in that case It looks like the process 1 runs `_check_all_processes_locks` correctly and then finishes and releases its lock before process 0 even managed to to run `_check_all_processes_locks` correctly. Strange! I changed the way the rendez-vous is done @thomwolf , let me know what you think.
The idea is that the master process has an additional lock `rendez_vous_lock` to tell every other process to wait for everyone to be ready before starting to write
There were CI bugs where a distributed metric would try to read all the files in process 0 while the other processes haven't started writing.

To fix that I added a custom locking mechanism that waits for the file to exist before trying to read it