Use more reasonable timeouts for some jobs

[StanFromIreland]

A job that on average, takes under half a minute, does not need a 60 minute time out. As such, when something goes wrong and the job hangs we are needlessly wasting CI resources. So I propose some slightly stricter timeout-minutes. They are all still quite generous, however, giving around 2-4x the average time.

Also, drop actions/setup-python in tail-call.yml, it's not needed for anything.

[webknjaz]

Yes, please!

Here's some more context from the past:

• #25471
• #88054 (comment)
• #146376

[webknjaz]

They are all still quite generous, however, giving around 2-4x the average time.

If we wanted to be really precise, we could have step-bound timeouts with specific I/O (deps installs) or test runs capped. One other thing to consider could be that when you take measurements of the old job runs, sometimes they show cache-optimized timings and when that cache gets invalidated, the time will be different. My strategy is to find the slowest non-cached run and give it some percentage on top.

[webknjaz]

(I'd probably prefer to have this in a standalone PR, FWIW)

[StanFromIreland]

I think it's fine to include it, it's just clean up after all. I presume it was copy-pasted from the JIT workflow. CC @Fidget-Spinner (I think you created tail-call.yml?)