Add feature-flagged secrets page
What does this MR do and why?
For Frontend (Tanu-Key): Create feature flag and ba... (#424452 - closed)
This MR adds a feature-flagged empty page (at the project level and at the group level) with an empty vue app that we can build the Frontend: GitLab Secrets Manager GA (&11373 - closed) inside of.
This is in ee/ for now because we're unsure what the pricing model will be, we can always move it out later if we need to 
It may be helpful to review this commit-by-commit because the first commit sets this up for projects, then the second commit builds on that to make it work for groups:
- 
Add feature-flagged project secrets page (!131224 (737b7da6))
- Create tanukey_ui feature flag, render 404 unless enabled
 - Add project secrets route, basic controller+spec, basic helper+spec
 - Add page haml, page index.js, root index.js, empty SecretsApp component
 
 - 
Do the same for group secrets (!131224 (4bd868ca))
- Add group secrets route, controller+spec, page haml, page index.js
 - Add group params into helper+spec, root index.js, SecretsApp
 
 
... and further commits make changes to the files established above.
Screenshots or screen recordings
| Before | After | 
|---|---|
![]()  | 
![]()  | 
How to set up and validate locally
Check out the branch and enable the feature flag for a root group:
git checkout tanukey-ui-boilerplate
echo "Feature.enable(:ci_tanukey_ui, Group.find_by_full_path(\"gitlab-org\"))" | gdk rails c
- have developer-or-higher access to a root group and enable the feature flag for that group
- 
note: make sure this is a root group - enabling the flag for a subgroup will have no effect because we check for the flag on the 
project.group.root_ancestor/project.root_ancestor 
 - 
note: make sure this is a root group - enabling the flag for a subgroup will have no effect because we check for the flag on the 
 - navigate to the root group, for example: http://gdk.test:3000/gitlab-org
 - insert 
/groupsinto the url and add/-/secretsonto the end of the url: http://gdk.test:3000/groups/gitlab-org/-/secrets - open Vue devtools and verify that there is a 
<GroupSecretsApp>on the page which is receiving the correctgroupIdandgroupPath - all descendants of the group for which the feature flag is enabled should show secrets pages - so navigate to any subgroups and projects that belong to the group (that you also have developer-or-higher access to) and repeat the process:
- navigate to the project: http://gdk.test:3000/gitlab-org/gitlab-test
 - add 
/-/secretsonto the end of the url: http://gdk.test:3000/gitlab-org/gitlab-test/-/secrets - open Vue devtools and verify that there is a 
<ProjectSecretsApp>on the page which is receiving the correctprojectIdandprojectPath - navigate to some subgroup: http://gdk.test:3000/gitlab-org/gitlab-test/some-subgroup
 - insert 
/groupsinto the url and add/-/secretsonto the end of the url: http://gdk.test:3000/groups/gitlab-org/gitlab-test/some-subgroup/-/secrets - open Vue devtools and verify that there is a 
<GroupSecretsApp>on the page which is receiving the correctgroupIdandgroupPath 
 - any groups and projects outside the root group for which the feature flag is enabled should not show secrets pages
 
additional optional testing:
- add any path onto the end of the secrets url, i.e. 
[group or project url]/-/secrets/123/456, and verify that the secrets page is still displayed (this will allow us to link directly to specific pages in this vue app later on) 
to run specs:
yarn install
yarn jest frontend/secrets
bundle install
bundle exec rspec ee/spec/requests/projects/secrets_controller_spec.rb ee/spec/requests/groups/secrets_controller_spec.rb ee/spec/helpers/secrets_helper_spec.rb
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
- 
I have evaluated the MR acceptance checklist for this MR.  

