Follow-up on gitaly updates on master

In #222497 (closed) we decided to stop bumping gitaly version in auto-deploy branches, but instead, update it directly on master.

This will allow us to leverage the already existing master:broken workflow.

release-tools!1062 (merged) implemented the first iteration of this and it's governed by the update_gitaly feature flag in release-tools and components:update schedule.

Current status

components:update schedule will run once every hour and create a new merge request to bump GITALY_SERVER_VERSION on GitLab master.

If another merge request is already present, the pipeline will do nothing.

Areas of improvement

In the current situation, there's no notification in case of a pipeline failure.

This query will show if there is an open merge request, and in case of failure it will require manual intervention.

Temporary manual actions to monitor and unblock the situation

This is a set of instructions to temporary monitor the situation

• check for open merge requests with with this query
• it will show no more than one merge request, in case of a pipeline failure it will require manual intervention.
• look at the failure, if it looks unrelated to gitaly, it's likely a master:broken or failureflaky-test. Open the pipelines tab and click run pipeline. This will run a pipeline for merge result
• if look gitaly related, notify the gitaly team

If someone updates GITALY_SERVER_VERSION with another MR, we may have a merge conflict.

In such unlikely circumstances, the better option will be closing the merge request and deleting the release-tools/update-gitaly branch. release-tools will take care of creating a new one in about 1hr