Current Behavior

In the frontend code we associate a Role created by the DSPO backend folks that helps the Service Account for a notebook go through the auth process with the OAuth Container. (on create | on toggle start)
An Edit Permission user cannot do this operation. So they'll never be able to use the Elyra plugin in notebooks.h3. Expected Behavior
We move the logic to the server – on creation of the notebook, it needs to call a custom backend route to create the RoleBinding (same logic createRoleBinding on the frontend – see current behaviour for code snippets).
Notes:

• This is temporary – we should not be creating more backend business logic
• Eventually we need to either migrate to the user controlling the notebook itself (Role is not needed at that point) or we follow through on a Dashboard Controller that will watch for new Notebooks and add the role binding

Steps To Reproduce

1. Create a DS Project
2. Create a Workbench (stop it once it beings)
3. Create a Data Connection & DSP Server
4. Create another Workbench
5. Re-enable the first Workbench

Both workbenches should have a secret and there should be two RoleBindings, one to each Notebook Service Account.h3. Workaround (if any)
Have Project "Admin" level permissions

 h3. Anything else
Important notes:

• Role binding must be hardcoded on the backend so it cannot be abused to grant other permissions
• We should check the users access to the Notebook – they should not be allowed to use our endpoint to just grant the service account access – we should check the ability to edit the Workbench in question