vault-kv relation is broken when not using network spaces

In the following change
https://github.com/openstack-charmers/charm-interface-vault-kv/pull/5/files

This check is not robust enough:
if not (addr and is_address_in_network(bound_cidr, addr)):
    continue

In the cases of CMR and on AWS where instances may be on different CIDRs for internal networks, it is not safe to assume the local instance's space binding will be on the same CIDR as the remote's ingress address.

Per cory_fu:
[The bigger issue is] get_api_url() needs to be called with vault's ingress address for the specific relation that it's be advertised on, rather than assuming it's going to be one of the extra-bindings spaces.

The vault charm needs to set it's ingress address appropriately for the given relation. The setting of the ingress address may be spaces aware.

Another way to look at this, the vault-kv change has it the wrong way around, the ingress setting that is important is on the vault side not the client side.

@thedac I think the code as it is is ok since it is already using the ingress-address from the remote unit i.e. the address the local unit is bound to on which it has received relation data from remote unit.

https://paste.ubuntu.com/p/K3fsYW9k37/

https://review.opendev.org/#/c/682164/
https://github.com/openstack-charmers/charm-interface-vault-kv/pull/6

Gerrit review is no longer valid, only the interface PR.

https://github.com/juju-solutions/layer-vault-kv/pull/7 fixes the permission denied at the end of long running hooks