Redesign component level locking

[nijel]

Describe the problem

The component level locking might be too broad for some situations (see #13345). It was introduced to avoid concurrency isues like #5686.

The problematic operations being:

• Changing strings, these should be handled by select_for_update and should not need component level lock. This needs to be verified.
• Creating new strings (add, parsing files). As these are newly created strings or translations, the row level locking will not help. This might be the remaining needed for component locking.
• Batch updating checks. This happens asynchronously in the Celery task, which holds component lock.
• Updating source checks. This is now synchronous while creating translations. Moving it to a Celery task might be better for both observed performance and data consistence. With it in place, there might be a separate lock for updating checks.

Describe the solution you would like

Analysis of the locking and what is actually needed to lock to avoid consistency issues.

Describe alternatives you have considered

No response

Screenshots

No response

Additional context

No response

[nijel]

Once #8770 is implemented, the lock for changing strings could be probably removed as that will no longer trigger commit (and the string updates are using SELECT FOR UPDATE).

[nijel]

#15250 removes component locking for bulk edit and automatic translation.