Feature: Better experience for modifying RoleAssignments

[bmwinstead]

When RoleAssignments are modified, ASO can naively just try to update the existing RoleAssignment object. This results in an error - RoleAssignmentUpdateNotPermitted: Tenant ID, application ID, principal ID, and scope are not allowed to be updated. This means that externally we have to be responsible for knowing when to, and deleting/recreating the RoleAssignment. It would be cool if ASO either:

1. Made the fields you can't change immutable in Kubernetes so you can't get into this state.
2. (preferred, maybe flagged?) Understood when the user was modifying an immutable field and triggered a deletion and re-creation of the underlying RoleAssignment object for you.

[theunrepentantgeek]

This is a good idea - building on the design of ASO as a goal seeking system.

I'll schedule the design work for this for our next release; once that's done, we can look at where it fits in our backlog.

[theunrepentantgeek]

We need to sort out write-once properties #1443 Some design work is required.

[matthchr]

This is something that would be great to improve upon. The delete+recreate would need to be opt-in (temporary loss of permissions in production is scary), but in general at least propagating the read-only fields would be ideal.