Hide stale data on relation broken

Can you comment here Ian?

The linked issue mentions that JUJU_REMOTE_APP is sometimes set and sometimes not.

The question becomes should it be set at this point (we need to make this behaviour consistent whatever the decision)

And should the departing side data be visible in this hook as John says it should be in the issue.

relation-broken should have the JUJU_REMOTE_APP value set in my opinion. This hook runs when all remote related (counterpart) units have left the relation and this unit on which the hook runs is ready to leave scope.

In my view, at that point, there can be no expectation that the unit relation data bags have any data; the relation is broken after all and the counterpart units are no longer known to the local unit. This might differ from what John says on the linked issue so we should discuss it. In my view, any cleanup that requires data should have been done in the departed hook.

Having said that, the current implementation might still report that the relation application data bag has data. Since this is app level, perhaps there's an argument that data there could be needed to do any final app level work.

fwiw, this caused some pain for me recently when trying to write a relation library that has a getter for the relation data. Effectively:

```
class RelationHandler:
  def get_relation_data(...):
    ...
    return data_from_the_relation_in_a_nice_format
```

The pain I hit was that I wanted the getter to always return only the applications that are still here, and omit the data from a departing app if called on a relation-broken event. But to do that really cleanly in python, it means I need to pass the `event` to `get_relation_data`, which basically means `event` gets passed everywhere.

As a hack, I made `get_relation_data` inspect the juju environment variables to see if this is a relation-broken, and if so to omit the departing app's data. But this sure felt harder than it needed to be.

For reference: https://github.com/canonical/kubeflow-dashboard-operator/blob/e8805385bb0ece2f97caba20ee4e1749681d865f/lib/charms/kubeflow_dashboard/v0/kubeflow_dashboard_sidebar.py#L161

The bug here is that the unit still sees the relation Id of the broken relation. We should fix this.

Why is this in the wishlist? We are currently forced to implement all kinds of workarounds that are outside of the charms responsibility to combat this.

I'm guessing it was marked as Wishlist prior to the mid-cycle where we had discussions about how best to deal with the issue.
The plan of record is to change the behaviour of the "relation-ids" command so that in the relation-broken hook, the relation id of broken relations is no longer reported. Note that relation-get behaviour will be unchanged in case there are charms that explicitly want to look at relation data even during the broken hook. Changing this has the potential to break too many charms.