feat: add an option to restrict comm between units of the charm

[adhityaravi]

Issue

fixes issue #106

Solution

• The ServiceMeshConsumer now includes a bollean argument auto_allow_intra_app_access
• When set to True, the build_mesh_policies method automatically appends an UnitPolicy with from the target apps service account selecting all the pods with the target app label

Testing Instructions

Can be tested using scaled Service Mesh Tester with more than 1 unit by setting the auto_allow_intra_app_access in the ServiceMeshConsumer to true and curling another units pod url from a unit.

[adhityaravi]

A few questions -

• The auto_allow_intra_app_access is not dynamic meaning for ex. it cannot be parametrized as a charm config to allow the user to enable ti and disable it neither does it observe any juju event. IMO it wasnt necessary.
• The auto_allow_intra_app_access name is debatable - I dont like it the best but I couldnt think of a better alternative that wasnt too long.

Opinions on both?

[simskij]

• The auto_allow_intra_app_access is not dynamic meaning for ex. it cannot be parametrized as a charm config to allow the user to enable ti and disable it neither does it observe any juju event. IMO it wasnt necessary.

That's fine. Should default to allowing to not break the current behavior. I'd invert it to signal that it's an opt-out.

• The auto_allow_intra_app_access name is debatable - I dont like it the best but I couldnt think of a better alternative that wasnt too long.

restrict_crossunit_communication or similar seems like a reasonable name.

[adhityaravi]

Doc update here

[dstathis]

Let's make this name a bit shorter. peer_communication is my suggestion.

[dstathis]

Also I think it should be an allow option and default to false. In other words, apps should not be able to talk to themselves unless they set this to True.

[adhityaravi]

I like peer_communication the best of all the suggestion. I will go with that.

[dstathis]

• The auto_allow_intra_app_access is not dynamic meaning for ex. it cannot be parametrized as a charm config to allow the user to enable ti and disable it neither does it observe any juju event. IMO it wasnt necessary.

That's fine. Should default to allowing to not break the current behavior. I'd invert it to signal that it's an opt-out.

• The auto_allow_intra_app_access name is debatable - I dont like it the best but I couldnt think of a better alternative that wasnt too long.

restrict_crossunit_communication or similar seems like a reasonable name.

The reason I think this should be opt in is that it forces the charm author to actually acknowledge the flag and think about it. I don't think we really care about the breaking change at this point since we are the only current consumers. I am not strong on this so happy to go with whatever @simskij says in response to this.

[adhityaravi]

superseded by #112