An existing set of reactive flags for the cluster_connected handler may lead to a resource configuration race condition

[Dmitrii Shcherbakov]

Some of our reactive charms have a latent issue in that they use `when_not('ha.available')` in the set of flags for cluster_connected.

https://opendev.org/openstack/charm-gnocchi/src/commit/074527a30378337eb504d3682dc224291469a2da/src/reactive/gnocchi_handlers.py#L137-L143
https://opendev.org/openstack/charm-octavia/src/commit/68536aee5aeedfb0c62ba2a115be5512bd46f37c/src/reactive/octavia_handlers.py#L212-L218

@reactive.when('ha.connected')
@reactive.when_not('ha.available')
def cluster_connected(hacluster):

The issue is subtle since ha.available is set based on a key set by an hacluster unit (clustered="yes") which is not gated on the availability of resource configuration set by the primary unit:
https://opendev.org/openstack/charm-hacluster/src/commit/574cc217be16a68d4e75b46cacf077f927f31060/hooks/hooks.py#L529-L530

https://review.opendev.org/#/c/743212/ - comments from this review (see the attachment) indicate that if multiple `when` conditions are there preventing cluster_connected from running on ha-relation-joined, then on the next execution ha.available will be set and block cluster_connected from being run.

I think we need a separate flag such as `ha-resources-exposed` to be used as a `when_not` condition for cluster_connected.