UI: ACL Roles cont. plus Service Identities

[johncowen]

This PR continues on from #5635 and adds 'Service Identities' to the UI.

Service Identities

Service Identities are more or less the same thing as Policies in that they are essentially a Policy with a predefined Rules template which you can see here.

As each Service Identity only needs a ServiceName to produce the templated Policy, only the ServiceNames are saved via the API (as a list/array on the parent object) for example

{
  ...
  Policies: [{...}],
  ServiceIdentities: [
    {
      ServiceName: ''
    }
  ]
}

In terms of the UI, we present the same form for creating/editing a ServiceIdentity as we do for creating/editing a Policy:

And we treat them in the UI as a 'type' of Policy, as essentially that is what they are. There is also potential down the line for further templated Policies, so we've added a new 'template' field to the Policy objects, normal Policies having an empty template.

This work contains serialization/normalization to reflect that, following the current project conventions in handleResponse and dataForRequest (#5637 🔜 will move this into the serializer using respondFor...). We did this using Adapter Mixins as we need the functionality for Policies and Roles, this should also make it trivial to move it elsewhere when we need to.

Other

{{code-editor}} changes

We have a {{code-editor}} component which wraps ivy-codemirror. We did 2 things here:

1. Altered our readonly logic for our wrapping component.
2. Added the ability for block usage (as opposed to a value="" attribute) to make the component feel more a like a <textarea>:

{{#code-editor}}
  service "name" {
  
  }
{{/code-editor}}

name -> type

The form components from #5635 now use a type attribute rather than name (thinking here being: <input type="text" />, <Form type="policy" />)

Tests

The nested nature of the modals (tokens > policies, roles > policies, tokens > roles > policies) here also meant we needed to create a similar nested approach for our PageObjects, and a way to select/find deeply nested PageObjects using our Gherkin steps. We've added the ability to deeply select/find PageObjects via our Gherkin steps using dot syntax with steps like:

And I click delete on the roles.selectedOptions
And I click submit on the roles.form
And I click submit on the roles.form.policies.form
Then I fill in the roles.form.policies.form with:
---

This will also now let us select/find certain indexes in lists:

And I click actions on the roles.form.policies.10

The grammar isn't quite ideal here but thats something we can look at at a later date. We've also maintained the past grammar, but moving forwards we'll deprecate that and work to merge some of the repetitive code used in the steps - you can see the beginnings of some of this work here

We also moved some of our acceptance tests that use policies and roles so we can make better used of looping/tables. Previously we would have had to repeat tests in dc/acls/tokens/policies and dc/acls/roles/policies, so we instead made dc/acls/policies/as-many and loop over both tokens and roles for each test in here.

---

Lastly, similar to the previous #5635 PR this is not quite how we'd like to do this. We've briefly discussed this with @meirish , but ideally it requires a deeper RFC which we plan to follow up with.