Fix flaky test execution caused by `Thread`
Author: ydshieh
Pull request: yes

# What does this PR do?

As discussed offline:

> Would it possible if we change Thread to Process below :pray: ?
I know it's not good to change code that is working and making sense for the sole purpose of testing, but Thread  (without join) here making some test(s) flaky failing
test_cached_model_has_minimum_calls_to_head
where we count the number of calls to Hub. Some other tests that (eventually) calling from_pretrained  entering Thread line  will affect test_cached_model_has_minimum_calls_to_head
because they are running at the same time in the same process.
There are other solutions, but the changes involves patching (a lot of) tests (so at conftest level which is not good neither IMO.
https://github.com/huggingface/transformers/blob/d5cf91b3462b5ed57260074a0708f09b16e787a8/src/transformers/modeling_utils.py#L3842

----------------------------------------------

To check the PR works (make sure tensorflow is available): 

> python gradio2.py

where `script.py`
```python
for i in range(20):
    import os
    os.system('python -m pytest -v tests/models/auto/test_modeling_auto.py tests/models/auto/test_modeling_tf_auto.py -k "test_from_pretrained_identifier or test_cached_model_has_minimum_calls_to_head"')
    # or running several times on CI workflow: it's flaky and not easy to reproduce
    # or add `time.sleep(0.5)` at the beginning of `auto_convenanorsion`

```

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34966). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Hi @ydshieh - FYI this change appears to have broken some unit tests in DeepSpeed, specifically where we download a model.  I'll look at ways to resolve this, I assume it is an issue in multiprocessing/threading.

@loadams Thank you for informing us. Hope there is a way that could work in both cases 🙏 Let me know if there is anything we can help here.

@ydshieh I'm also experiencing issues here for Sentence Transformers/Cross Encoder models, see https://github.com/UKPLab/sentence-transformers/issues/3129

In short: `multiprocessing.Process` never works when not inside of `__name__ == "__main__"`. I recognize that most programs should be using that line, but I'd rather not force it on my users.

If one of my users loads any model that only has a `pytorch_model.bin`, then it'll fail, e.g.:
```python
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("embaas/sentence-transformers-gte-base")
```
or
```python
from sentence_transformers import CrossEncoder

model = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")
```
which internally call
```python
from transformers import AutoModel

model = AutoModel.from_pretrained("embaas/sentence-transformers-gte-base")
```
or
```python
from transformers import AutoModelForSequenceClassification

model = AutoModelForSequenceClassification.from_pretrained("cross-encoder/ms-marco-MiniLM-L-6-v2")
```

All of these get:
```
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

        To fix this issue, refer to the "Safe importing of main module"
        section in https://docs.python.org/3/library/multiprocessing.html
```

- Tom Aarsen

> Hi @ydshieh - FYI this change appears to have broken some unit tests in DeepSpeed, specifically where we download a model. I'll look at ways to resolve this, I assume it is an issue in multiprocessing/threading.

Hi @loadams FYI: it's reverted back to use `Thread` in #35236 (as there are other issues reported)

> should be using that line, but I'd rather not force it on m

@ydshieh - thanks for the update!