[ci] job timeout should only take `script` section into account.
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=22353)
</details>
<!--IssueSummary end-->
### Summary
Each job has a timeout (either per runner or per repository), supposedly to keep stuck and out-of-bound jobs under control.
Now there are a few time-consuming stages, that can be influenced by the user, namely:
- `before_script`
- `script`
- `after_script`
However, there are some more steps involved that add up to the total time, e.g.:
- docker image fetch
- `pre_clone_script` of the runner.
It would be great, if the timeout (at least the per-project timeout) would only take the user-accountable stages into account.
### Steps to reproduce
- setup CI-runner `myrunner`
- configure the runner with a `pre_clone_script: sleep 1000`
- configure project `FOO` to use CI/CD
- configure the CI-timeout to be `10 minutes`
- configure a job to be run on `myrunner`
- trigger a pipeline for project `FOO` to be executed on runner `myrunner`
### What is the current *bug* behavior?
Notice how the job will always fail due to timeouts, regardless of the actual time spent in the (user-controlled) `.gitlab-ci.yml`
### What is the expected *correct* behavior?
I would have expected the timeout to only take the actual user-defined parts into account (`script`, `before_script`, `post_script`,...).
So even if the `pre_clone_script` takes *long*, or fetching a (largish) docker-image takes *long*, this doesn't take away time from the actual build process.
### Possible fixes
Have the per-project `timeout` only take those values into account that can be influenced by the user.
In order to catch stalled `pre_clone_script` runs or similar, there might be an additional (per-runner) timeout that only applies to the steps outside ther user's control.
issue