Upgrade to Relation

[PietroPasotti]

This PR addresses several limitations of the existing Relation implementation:

1

we did not have enough data in the Event datastructure to mock the following relation-event-specific envvars

• JUJU_UNIT_NAME
• JUJU_APP_NAME
• JUJU_DEPARTING_UNIT -- only for *-relation-departed

This PR adds that functionality and corresponding tests.

2

We lacked facilities to correctly mock peer and subordinate relation types.
This PR adds two new types: PeerRelation and SubordinateRelation to address that need.

[PietroPasotti]

Up for discussion:
I made the choice to have:

PeerRelation(local_app_data={}, local_unit_data={}, peers_data ={})
SubordinateRelation(local_app_data={}, local_unit_data={}, remote_unit_data={})

rather than:

Relation(type='peer', local_app_data={}, local_unit_data={}, remote_units_data={})
Relation(type='subordinate', local_app_data={}, local_unit_data={}, remote_units_data={0:{}})

This allows to:

1. have named kwargs that make more sense in the context of the relation type. Instead of 'remote', which suggests that the application is different, use 'peers'. For subordinates, use 'primary' instead of 'remote' as terminology.
2. prevent at the root some user errors: a peer relation has no 'remote app databag' that can be different from the 'local' one. Using a different constructor without a remote_app_databag gets rid of that risk. Similarly, in the context of a subordinate relation, "this unit" can only see ONE 'remote unit' at a time (the primary it is attached to). This means we'd have to impose constraints on the contents of remote_units_data conditionally on the type param, which felt like a bad idea.

On the other hand:

• two extra types to maintain, import, know about...
• ?

@simskij @benhoyt @Abuelodelanada @sed-i @rbarry82 @lucabello @dstathis thoughts?

[ghislainbourgeois]

Overall I like the approach, I think the UX is good.

[ghislainbourgeois]

I left only a small nitpick, feel free to close it if you don't think it is doable/valuable.

[simskij]

Up for discussion: I made the choice to have:

PeerRelation(local_app_data={}, local_unit_data={}, peers_data ={})
SubordinateRelation(local_app_data={}, local_unit_data={}, remote_unit_data={})

rather than:

Relation(type='peer', local_app_data={}, local_unit_data={}, remote_units_data={})
Relation(type='subordinate', local_app_data={}, local_unit_data={}, remote_units_data={0:{}})

This allows to:

1. have named kwargs that make more sense in the context of the relation type. Instead of 'remote', which suggests that the application is different, use 'peers'. For subordinates, use 'primary' instead of 'remote' as terminology.
2. prevent at the root some user errors: a peer relation has no 'remote app databag' that can be different from the 'local' one. Using a different constructor without a remote_app_databag gets rid of that risk. Similarly, in the context of a subordinate relation, "this unit" can only see ONE 'remote unit' at a time (the primary it is attached to). This means we'd have to impose constraints on the contents of remote_units_data conditionally on the type param, which felt like a bad idea.

On the other hand:

• two extra types to maintain, import, know about...
• ?

@simskij @benhoyt @Abuelodelanada @sed-i @rbarry82 @lucabello @dstathis thoughts?

I do indeed agree that your first suggestion makes the most sense. To me, a good rule of thumb usually is: If you can avoid args, do.