Use pessimistic locking when accessing Terraform state

What does this MR do and why?

Use pessimistic locking when accessing Terraform state

Previously Terraform states were accessed with an optimistic lock, which retries if an update fails due to concurrent modification.

This worked as intended when the file data was stored on the state record itself, however storing individual versions separately means the state record is never updated when creating a new version, giving no opportunity for it to become stale and therefore defeating the locking.

In some circumstances this could lead to the same version being created twice, which fails a unique constraint.

Explicitly locking the record should force the caller to wait until the previous update has finished, at which point it will see the newly created version (and not attempt to create it again).

#299411 (closed)

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.