Filter Secret Engine List view by engineType and/or name

[Monkeychip]

This PR adds two filtering options on the Secret Engine LIST view: filter by engineType (e.g. kv) and/or filter by engine name (e.g. secret). See community Issue for this request here.

• There was a noticeable lag when having 100+ secret engines in rendering this page. This was always an issue, but very noticeable when testing filtering by a name with 100+ secret engines. After brainstorming solutions with the team, Jordan suggested simplifying the template structure. We had an older, single use contextual component called LinkableItem. TLDR: I changed the structure to match the list structure used in the Auth LIST view, backing out the contextual component. While this expanded the row count for the backends.hbs file, it removed 3 components, and greatly increased the page speed. This is a huge win for customers that have a lot of secret engines.
• I glimmerized the controller and hbs file.
• I simplified the structure of the template file by adding the property isSupportedBackend to the model and removing the two lists: supported and unsupported that were rendered in the view.
• I added two other model properties that replaced two {{let}} definitions in the contextual components. This made this a lot easier to simplify and clean up the passing around of params.

Screen.Recording.2023-05-05.at.11.12.52.AM.mov

In another PR:

• Created a Sparkle ticket to add pagination to this view.
• Created a ticket to fix SearchSelect active state, which is a bug from the bulma removal.

If you want to run a script to add loads of secret engines, here is a bash script

echo "create lots of secret engine mounts"
for ((n=1;n<101;n++)); do
  vault secrets enable -path=kv-$n kv
done

[Monkeychip]

Does this to the search select. I needed this functionality because it does not make sense for them to filter by engine Type when they are always going to see one item in the list if they filter by name.

[Monkeychip]

open to suggestions on ways to make this cleaner, but for context here is the flow:

1. On init, this getter returns the full list of secret engines to display on the template.
2. When someone filters, either by name or engine type, this list is updated. This update is triggered because of the tracked properties that change inside the getter when someone filters by name or engine type.
3. This getter is used to create the options param passed into the SearchSelect components.

[hashishaw]

this is so much cleaner! 🥲 Great work. Added a couple comments, and I'll hold approving until the filtering tests are in here!

[hashishaw]

This route might be different for engines like pki and kmip, no?

[Monkeychip]

Good question. That is an issue when you click on the whole row, but not when you click on the menu to go to configuration. For example, for PKI when you click on the row it navigates you to the overview page. But the configuration page is the same for all. I confirmed the same behavior on this branch is seen on main.

[hashishaw]

🤦‍♀️ and then I approved it. Well, please ping me when the tests are written I'd love to take a look!

[Monkeychip]

🤦‍♀️ and then I approved it. Well, please ping me when the tests are written I'd love to take a look!

Will do! I think I'll finish the tests today, but return to the tests to double check and I'll return to your comments when I have a fresh brain. For now, just so I don't accidentally press something, I'll add the don't merge label.

[hashishaw]

Thanks for the test coverage! One small comment, but otherwise 🚀

[hashishaw]

I don't think we need to use .get anymore, we could instead do:

Suggested change

	return sortedBackends.filter((backend) => this.selectedEngineName === backend.get('id'));
	return sortedBackends.filter((backend) => this.selectedEngineName === backend.id);

But if that doesn't work for some reason I'd like to understand why!