swift-proxy charm doesn't work with new style keystone "only set relation data on leader" feature

[Alex Kavanagh]

During the 20.08 development cycle keystone gained a 'feature' such that it only sets the relation data for a client connect from the leader. This means that when the client inspects the relation data from 'n' keystone units that it is related to, only the leader will actually have any relation data pertaining to the identity information.

This is good from the perspective of performance (it means that only 1 relation-change has to be processed, rather than 'n' from 'n' keystone units).

Unfortunately, the swift-proxy charm was coded to expect that ALL keystone units would present the same information. Thus, if the last unit in the relation-list is not setting its data, then the swift-proxy charm has 'no' data (because it overwrites the previous units that it looked at) and this breaks the identity information.

Solution: code the charm to merge the data from all relations, which is how the charms.reactive framework deals with this scenario.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/744243

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/744243
Committed: https://git.openstack.org/cgit/openstack/charm-swift-proxy/commit/?id=1e8a448d0e53e068b75e60172831b22b84b49c00
Submitter: Zuul
Branch: master

commit 1e8a448d0e53e068b75e60172831b22b84b49c00
Author: Alex Kavanagh <email address hidden>
Date: Fri Jul 31 20:46:55 2020 +0100

    Alter handling of identity-service relation data

    This patchset changes the handling of the identity-service relation data
    from "the last connected charm in the relation-list is the data to use"
    to "merge non None data from all relations, with the last one winning."

    This is to handle the change in how keystone now sets relation data on
    the identity-service relation: only the leader actually sets the
    relation data. This means that the consuming charm only 'sees' relation
    data from leader, with no keys from the non-leaders.

    charms.reactive handles this by merging data from all the relations.
    This change exhibits the same behaviour.

    Change-Id: Ic77c0127ab9903c1596d2be882735acec3d2e2f9
    Closes-Bug: #1889930