#31894 - prevent concurrent design management git repo access

What does this MR do?

This MR mitigates issues related to concurrent git repo access by synchronizing design version creation with distributed locks ensuring that only one thread in one instance can upload/delete designs from a given design management repo at a time.

It deals with the git repo contention by synchronizing access to each project design repository. This is effective, but the following considerations need to be borne in mind:

• locking contending access means that resources can be tied up by blocked threads. This could lead to resource exhaustion, for example of PSQL connections. We mitigate this by having short TTL and exponential backoff to ensure resources are only held for a minimal time.
• synchronizing access to the git repo means that we may (in the future) have trouble scaling if any project sees sustained heavy use of design uploads.

Other approaches that are worth considering (either now or later):

• move away from git completely, and let the DB manage contention, as it does now for all our other records.
• scoping repos to design collections will make contention much less of a problem - rather than a large project needing synchronized access, we should be able to scale well by having many design collections we can lock and update in parallel. This is envisaged in the new architecture.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done