Reduce timing on CircleCI - part 1 (Use @slow for IntegrationTests)

[ydshieh]

What does this PR do?

Reduce timing on CircleCI.

Use @slow for some IntegrationTests.

Note that, for IntegrationTest class that have setupClass, even if a test method is fast, the setupClass might still take quite long time, if it downloads models. Even tokenizers may take 3 -5 seconds sometimes

[github-actions]

[For maintainers] Suggested jobs to run (before merge)

run-slow: aria, bark, hiera, imagegpt, jamba, llava, mamba, mbart, olmo2, plbart, rag, rt_detr, rt_detr_v2, speech_to_text, speecht5, tvp

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[Cyrilvallez]

Makes a lot of sense, except the imagegpt one! I think this is unrelated!

[Cyrilvallez]

I don't see how this can can the case when this is run on the CI? Because it does not have any accelerator available so no device-side assert triggered

Probably the issue is only the @run_test_using_subprocess which should not be necesary here I think!

[ydshieh]

This comment is from my previous PR #34213, and I am sure I did the investigation at that time :-).

This test call the one in the parent class GenerationTesterMixin in the file tests/generation/test_utils.py and it does use torch_device.

Of course, when running on CircleCI, the torch_device is CPU and the comment doesn't apply in this case. But we still need put run_test_using_subprocess so the problem won't occur when it's running on GPU enviornment.

I can of course make run_test_using_subprocess more flexible to accept some conditions, but it won't be done in this PR .

Let me know your opinion.

[ydshieh]

Merge now. Will address if there is further comment (which should be in a follow-up PR anyway)