if something goes wrong talking with the database connection (like a
disconnect or timeout) the parent `Lock` object will catch and simply
say that there was an error acquring the lock. However, waitAndSave and
waitAndSaveRead both store the lock in an internal store so trying to
re-acquire the lock with the same connection would result in a lock
confliected exception even though the lock was never acquired in the
first place.

This takes the fix from symfony#44828
and applies it to the waitAndSave and waitAndSaveRead methods on both
DoctrineDbalPostgreSqlStore and PostgreSqlStore.

…ndSave* (chrisguitarguy)

This PR was squashed before being merged into the 5.4 branch.

Discussion
----------

[Lock] Release Locks from Internal Store on Postgres waitAndSave*

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #45505
| License       | MIT
| Doc PR        | n/a

if something goes wrong talking with the database connection (like a
disconnect or timeout) the parent `Lock` object will catch and simply
say that there was an error acquring the lock. However, waitAndSave and
waitAndSaveRead both store the lock in an internal store so trying to
re-acquire the lock with the same connection would result in a lock
confliected exception even though the lock was never acquired in the
first place.

This takes the fix from #44828
and applies it to the waitAndSave and waitAndSaveRead methods on both
DoctrineDbalPostgreSqlStore and PostgreSqlStore.

Commits
-------

32a0f50 [Lock] Release Locks from Internal Store on Postgres waitAndSave*