Semantic check in host lock seems to unexpectedly allow force lock of controller (and storage-0 can no longer be unlocked)

[Matheus Machado Guilhermino]

Brief Description
-----------------
3 hosts in the quorum...all hosts are unlocked, enabled and available prior to the test
In the tc, storage-0 is locked
Then the tc attempts to lock controller-1 (which is rejected)
Then the tc attempts to force lock controller-1 (which is allowed but should be rejected)

Severity
--------
standard

Steps to Reproduce
------------------
3 hosts in the quorum...all hosts are unlocked, enabled and available prior to the test
Lock storage-0.
Attempt to lock controller-1 (which is rejected)
Attempts to force lock controller-1

Expected Behavior
------------------
There should be an additional mechanism to prevent force locking controller-1 when storage nodes are locked.

Actual Behavior
----------------
Controller-1 is locked and storage-0 can no longer be unlocked.

Reproducibility
---------------
100%

System Configuration
--------------------
3 nodes:
controller-0
controller-1
storage-0

Last Pass
---------
Unknown

Timestamp/Logs
--------------
N/A

Test Activity
-------------
Developer Testing

Workaround
----------
N/A

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/starlingx/config/+/887293
Committed: https://opendev.org/starlingx/config/commit/b73ab54bddfc0f532a94b9c5bbf216b8befea651
Submitter: "Zuul (22348)"
Branch: master

commit b73ab54bddfc0f532a94b9c5bbf216b8befea651
Author: Matheus Guilhermino <email address hidden>
Date: Tue Jul 11 10:19:43 2023 -0300

    Additional mechanism for unsafe force

    In some scenarios, a force operation should not override a
    protective semantic check, even when --force is used.
    To provide a way to bypass those semantic checks completely,
    a new "--unsafe" option is introduced.

    Whenever an unsafe scenario is identified, with or without using
    --force, the following message is displayed in addition to the
    specific warning:

    "Use --force --unsafe if you wish to lock anyway."

    This change includes a bypass for the following scenario (only
    one identified so far):

    3 hosts in the quorum:
    controller-0 unlocked and enabled
    controller-1 unlocked and enabled
    storage-0 unlocked and enabled
    Expected behavior:
    Storage-0 is locked
    Attempt to lock controller-1 (which is rejected)
    Attempt to --force lock controller-1 (which should be rejected)
    Attempt to --force --unsafe lock controller-1 (which is allowed)

    Test Plan:
    PASS: Fresh Install and Bootstrap (AIO-SX and Storage)
    PASS: Can't lock a controller when only 2 storage
          monitors are available
    PASS: Can't force lock a controller when only 2 storage
          monitors are available
    PASS: Successfully unsafe lock a controller when only 2 storage
          monitors are available

    Closes-bug: 2027685

    Change-Id: I1d9a57c472d888b9ffc9bbe3acd87fd77f84fa52
    Signed-off-by: Matheus Guilhermino <email address hidden>