minor #21578 [Lock] Explain 'retry' of lock stores over explicit 'no' (rvanlaak)

This PR was submitted for the 7.3 branch but it was squashed and merged into the 6.4 branch instead.

Discussion
----------

[Lock] Explain 'retry' of lock stores over explicit 'no'

The documented 'no' is quite explicit with regards to whether a store does not allow userland to use the lock's blocking behavior. Using 'retry' as more subtle wording, and reiterating the rationale behind retry below the table, explains that it's the lock class itself that handles blocking support.

Seeing the 'no' in the docs shocked me a bit, as it made me doubt many of the implementation I've made that leverage the lock's blocking behaviour. This PR makes the shock a bit more subtle.

<!--

If your pull request fixes a BUG, use the oldest maintained branch that contains
the bug (see https://symfony.com/releases for the list of maintained branches).

If your pull request documents a NEW FEATURE, use the same Symfony branch where
the feature was introduced (and `7.x` for features of unreleased versions).

-->

Commits
-------

46403c4 [Lock] Explain 'retry' of lock stores over explicit 'no'

Author: javiereguiluz

components/lock.rst

@@ -390,17 +390,20 @@ The component includes the following built-in store types:
 Store                                                       Scope   Blocking  Expiring Sharing Serialization
 ==========================================================  ======  ========  ======== ======= =============
 :ref:`FlockStore <lock-store-flock>`                        local   yes       no       yes     no
-:ref:`MemcachedStore <lock-store-memcached>`                remote  no        yes      no      yes
-:ref:`MongoDbStore <lock-store-mongodb>`                    remote  no        yes      no      yes
-:ref:`PdoStore <lock-store-pdo>`                            remote  no        yes      no      yes
-:ref:`DoctrineDbalStore <lock-store-dbal>`                  remote  no        yes      no      yes
+:ref:`MemcachedStore <lock-store-memcached>`                remote  retry     yes      no      yes
+:ref:`MongoDbStore <lock-store-mongodb>`                    remote  retry     yes      no      yes
+:ref:`PdoStore <lock-store-pdo>`                            remote  retry     yes      no      yes
+:ref:`DoctrineDbalStore <lock-store-dbal>`                  remote  retry     yes      no      yes
 :ref:`PostgreSqlStore <lock-store-pgsql>`                   remote  yes       no       yes     no
 :ref:`DoctrineDbalPostgreSqlStore <lock-store-dbal-pgsql>`  remote  yes       no       yes     no
-:ref:`RedisStore <lock-store-redis>`                        remote  no        yes      yes     yes
+:ref:`RedisStore <lock-store-redis>`                        remote  retry     yes      yes     yes
 :ref:`SemaphoreStore <lock-store-semaphore>`                local   yes       no       no      no
-:ref:`ZookeeperStore <lock-store-zookeeper>`                remote  no        no       no      no
+:ref:`ZookeeperStore <lock-store-zookeeper>`                remote  retry     no       no      no
 ==========================================================  ======  ========  ======== ======= =============
 
+When the store does not support blocking locks, the Lock class will retry to acquire
+the lock in a non-blocking way until the lock is acquired.
+
 .. tip::
 
     A special ``InMemoryStore`` is available for saving locks in memory during