Lowering of expected-osd-count configuration option does not trigger all relations

[Frode Nordahl]

In a deployment scenario where you have `expected-osd-count` set to N, only to find that one of your machines is malfunctioning during deploy, you would most likely want to continue with the functioning machines.

However, if you lower the `expected-osd-count` configuration option the ceph-mon does not re-run all relations, and in this instance the ceph-radosgw units did not get fsid and keys on their relation, and as such the units are stuck:
Unit Workload Agent Machine Public address Ports Message
ceph-radosgw/0 waiting idle 3/lxd/2 10.130.11.78 443/tcp Incomplete relations: mon
  hacluster-radosgw/2 active idle 10.130.11.78 Unit is ready and clustered
  logrotate/55 active idle 10.130.11.78 Unit is ready.
  public-policy-routing/30 active idle 10.130.11.78 Unit is ready
ceph-radosgw/1* waiting idle 4/lxd/2 10.130.12.86 443/tcp Incomplete relations: mon
  hacluster-radosgw/1* active idle 10.130.12.86 Unit is ready and clustered
  logrotate/51 active idle 10.130.12.86 Unit is ready.
  public-policy-routing/27 active idle 10.130.12.86 Unit is ready
ceph-radosgw/2 waiting idle 5/lxd/2 10.130.13.72 443/tcp Incomplete relations: mon
  hacluster-radosgw/0 active idle 10.130.13.72 Unit is ready and clustered
  logrotate/33 active idle 10.130.13.72 Unit is ready.
  public-policy-routing/13 active idle 10.130.13.72 Unit is ready

From cursory view of the ceph-mon config-changed helper, it does indeed not rerun all of the client type relations, so perhaps we need to extend it to do so?