Implement logic for each API action that impacts the access decision endpoint and builds a replication event .

Which endpoint are affects it is listed here :https://docs.google.com/spreadsheets/d/1DT_9chGYCKUYg0-T8FG4SLYyJVdA054KLTkQyFdNVaI/edit?gid=0#gid=0

The replication event should include relations to be added and removed.

This story is for /api/v1/groups/:uuid/principals/ 

Implementation notes

• Concurrency control. Please take into account the code comments introduced with https://github.com/RedHatInsights/insights-rbac/pull/1180. Notably, the group likely needs to be locked during the course of the update. We don't need a separate object to store user-group membership mappings because that is already stored in RBAC. So the replication for group principal events can be independent of BindingMapping, Access, and Policy changes.
• Replication event computation. Principal changes to groups are trivial to handle incrementally. Simply add/remove the principals using the existing IDs known by RBAC. Recalculating and replacing all of the relations for the affected roles in these cases is not a good idea. Because of shared system roles (which cannot be modified hence not relevant to Role create/update endpoints), this could result in the computation of 10s if not 100s of thousands of role bindings.
• Remove group membership from role updates. Group membership is currently included in dual write logic for roles. This helps for POC end to end relations, but it adds unnecessary extra work for the whole stack and complicated concurrency control. As part of this story group membership changes should ONLY dual write from this group endpoint.