Only update dependency if the status of its new commit is green

[nejch]

What would you like Renovate to be able to do?
This currently probably only applies to the git-submodules manager, but maybe people will find other uses for it.

Usually when a new dependency is available, it has gone through a CI/CD pipeline with quality checks, etc. But with git submodules, it just means a new push or merge to master/default branch, and the build may actually be broken or still in progress, so we can't be sure that we want to update this dependency.

It'd be great if renovate could handle this scenario and not update until the status is green, e.g. by providing an additional configuration option (pick your favorite naming.. 😁):

  "git-submodules": {
    "enabled": true,
    "onSuccess": true
  }

Describe the solution you'd like
This write-up will be very GitLab-focused as I'm most familiar with its API but the workflow should be similar anywhere. I don't know enough to take this on by myself but I'll try to describe as much as possible below and cover gotchas, please bear with me, I might also be overthinking things, it's probably easier for public repos. 😁

For an initial feature, supporting submodules on the same instance would probably be a good start, since a) the bot's token can be reused for API calls, and b) we know the type of provider (GitLab/GitHub etc). I'm not yet sure how this would work for private submodules on other instances. Maybe additional configuration to provide a token for a specific base URL, and create an auth session so that API calls to URLs computed for those submodules would also work (but I'm talking out of my ass here, I know almost zero js/ts).

1. We're already getting the latest commit hash and the clone URL of submodules in lib/manager/git-submodules/extract.ts, but we need to also construct the API URL from that. Note that for GitLab, for API calls the path to the repo must be URL-encoded unless we use IDs.
2. for relative submodule URLs (../bla.git) this should be relatively easy based on our repo's api url
3. for absolute HTTPS URLs, if our instance baseUrl matches the submodule instance base URL, we can extract the path. For other instances... see my comment above (maybe preconfigured additional baseUrls would help)
4. for SSH and Git protocol URLs, we could (at least for gitlab) use our superproject's ssh_url_to_repo variable and compare the base URLs to get to the API URL. For other instances, this is a bit tricky, because there are some edge cases: we need to clean up non-default SSH ports if present, but also consider that only the HTTPS URL might be served in a subdirectory (https://example.com/gitlab). Maybe try some sane defaults of git@git.example.com -> https://git.example.com.
5. We now have the API URL and commit hash, so we could reuse/extend getStatus for the current repo to support other repositories to fetch the status, see GitLab example:

   renovate/lib/platform/gitlab/index.ts

   Line 309 in e6453ae

   const url = `projects/${config.repository}/repository/commits/${branchSha}/statuses`;

6. If the status is not green, don't do anything yet. :)

Describe alternatives you've considered
Custom webhooks/API calls at the end of pipelines on the dependency side, but I'd like to stop doing this as it creates a messy web of dependents to maintain, and doesn't really work with scheduled runs.

If anyone else can find other scenarios for this please chime in! Sorry for the mini-novel :)