Set Relation.app via JUJU_REMOTE_APP or "relation-list --app" if no units

[benhoyt]

Charm errors were happening because we were setting Relation.app from the app of the first unit, but if an event was fired before any units had started up (this happens on relation-created, for example), the app field was None and this caused a KeyError later when charms did things like event.relation.data[event.app] (event.app was None).

The code still starts with the current method (first app of the units), but in the case when that doesn't work because there are no units, we fall back to:

1. If the relation in question is this event's relation (JUJU_RELATION_ID), then use JUJU_REMOTE_APP as the remote app name.
2. If it's not this event's relation, use relation-list --app to fetch the remote app name (--app was introduced in Juju 2.8.1).

Fixes #175 and manifests itself as issues like https://bugs.launchpad.net/juju/+bug/1914415

[jameinel]

We discussed this in person, but it isn't complete as is.
The problem is that it assumes JUJU_REMOTE_APP is valid for all relations, while it is only valid for the current JUJU_RELATION_ID.
However, if we tracked those two pieces, we probably have a reasonable fix for #175 that would be backwards compatible with juju 2.7 and 2.8. And while it doesn't solve the overall modeling problem it does, at least, fix a common error case.

[jameinel]

I think this is certainly going in the right direction. A few small changes.
We also are missing the direct tests of the _ModelBackend (when the env var is set, when it is set but matches a different relation_id, etc)

[benhoyt]

@jameinel Ian pointed out that relation-list --app might exist already, and sure enough, it does! I've updated the code/tests to use that.

[jameinel]

Given the frequency of this pattern:

        except ModelError as e:
            if 'relation not found' in str(e):
                raise RelationNotFoundError() from e
            raise

(Which happens 3 times quickly together.)

I do wonder about trying to find commonality there, but it is a relatively short snippet. (it just happens to be easy to typo 'relation no found' and then never triggers but you don't notice.

I'm also not 100% sure what should happen if you ask for a remote application name but the relation doesn't exist. Is 'return None' the right answer here? The other _ModelBackend commands actually raise an exception, though at a higher level they do suppress the error.

[benhoyt]

I've added a _is_relation_not_found helper to unify and avoid typos.

Regarding returning None here -- it seemed right for this function (and is documented and used as such). Given that it's an internal function, I think it's fine, and we can always iterate later if we want to.

[jameinel]

Thanks for the updates

[hpidcock]

LGTM thank-you