get_remote_unit_name verified private_ip matching between principal
unit and telegraf itself. However, this might break in a multi-NIC
environment and there's no real need to run such check since telegraf
is a subordinate.
Possible cases:
1) Charms that can have more than one relation with telegraf (mysql,
pgsql, mongodb, etc. see the "requires" section of metadata.yaml).
Telegraf can run specific plugins + juju-info rel
Result: No more than a single telegraf unit becomes subordinate, so
rel['__unit__'] would return the same value for any relation
2) 2 charms living in the same container/metal, and related to
telegraf
Result: Each principal unit, using a diff charm each, will have its
own relation with telegraf (2 telegraf units will live in the node).
Each unit will return a different rel['__unit__'], as they have
different principal units
3) 1 charm living in a container/metal, and related to telegraf
Result: telegraf has a single "requires" relation and will return
rel['__unit__'] of its principal
When relating units with telegraf, the get_remote_unit_name function is
verifies the remote unit name by checking that the private-ip address in
the relation data matches the private IP address of the unit.
This breaks when using a network space with a unit IP address that is
not the juju-calculated private-ip address for the unit, which is kind
of the point of being able to specify an alternate network space.
This commit fixes this when using network spaces by using the unit's IP
address in the provided network space if available, falling back to the
unit's private address if a space is not configured/available (for
example, in juju 1.25 environments)