Operator: Refactor the canvas implementation to conform to decision #2

[LesterThomas]

Description

Refactor the canvas implementation to conform to decision #2.

The feature definition for this is described in issue #81

This includes updating the use cases, BDD, TDD and source code for the identity operator. I propose for the implementation, the first step will be to support TMF672 User Roles and Permissions in addition to supporting TMF669 Party Role Management. We should deprecate TMF669 and warn about it and remove it in N+2 release. This will allow existing components to continue to work, and give component vendors a realistic timeline to update to use TMF672.

[brian-burton]

There are two things we need to figure before we complete this feature:

1. What is the flow and order of preference for allowing use of either the TMF669 PartyRole Management API or the TMF672 User Roles and Permissions API or the simple list? We may need to handle the situation where two or more conflicting configurations are present in the Component CRD (e.g. there's a PartyRole Management configuration and a simple list).
2. What is the data model for each of the three? We know PartyRole Management because we'va already done that, so there's a good chance User Roles and Permissions will be the same, but we haven't got a model for the simple list case.

My suggestion to start the discussion is:

1. We should prefer User Roles and Permissions to support the API-first principle. We should accept the simple list if there's no User Roles and Permissions API as the list is the only real choice if there is no API. We should accept the PartyRole Management API as third choice as we know we will deprecate it in a couple of releases time.
2. Documentation here shows a current example of securityFunction. My suggestion would be to extend it as follows:

   securityFunction:
   controllerRole:
   - name: secConAdmin
     description: Controller role for the canvas security controller
   exposedAPIs:
   - name: partyrole
     specification: https://raw.githubusercontent.com/tmforum-apis/TMF669_PartyRole/master/TMF669-PartyRole-v4.0.0.swagger.json
     implementation: {{.Release.Name}}-partyroleapi
     apitype: openapi
     path: /{{.Release.Name}}-{{.Values.component.name}}/tmf-api/partyRoleManagement/v4
     developerUI: /{{.Release.Name}}-{{.Values.component.name}}/tmf-api/partyRoleManagement/v4/docs
     port: 8080 
   - name: usersandroles
     specification: https://raw.githubusercontent.com/tmforum-apis/TMF672_UserRolesPermissions/master/TMF672-UserRolePermission-v4.0.0.swagger.json
     implementation: {{.Release.Name}}-usersandroles
     apitype: openapi
     path: /{{.Release.Name}}-{{.Values.component.name}}/tmf-api/usersAndRoles/v4
     developerUI: /{{.Release.Name}}-{{.Values.component.name}}/tmf-api/usersAndRoles/v4/docs
     port: 8080
   dependantAPIs: []
   componentRole:
   - name: role1
     description: role1 description
   - name: role2
     description: role2 description

   This extends exposedAPIs with a second option for User Roles and Permissions. It also extends securityFunction with a componentRole array that lists names and descriptions of roles. To make the componentRole and controllerRole fields uniform, it also introduces a breaking change to controllerRole to make it an array the same format as componentRole.

This change would require a change to the BDD, TDD, CRD definition, component design guidelines and security controller.

Note that usersandroles/usersAndRoles may not be correct because there's an error in the source for TMF672 for which I've raised another issue.