Add feature flag for blocked repositories UI

[andrew-farries]

Description

Add a feature-flagged entry in the admin sidebar that will show a placeholder blocked repositories admin UI.

The feature flag is enabled for non-production environments (ie preview and staging).

Related Issue(s)

Part of #11030

How to test

Start the preview environment and see the new Repositories menu item in the Admin menu:

The link takes you to an empty placeholder page:

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview

[werft-gitpod-dev-com]

started the job as gitpod-build-af-feature-flag-for-blocked-repos-ui.11 because the annotations in the pull request description changed
(with .werft/ from main)

[geropl]

@andrew-farries When loading /workspace I see a blank page in 50% of the cases, or errors like this:

![image](https://user-images.githubusercontent.com/32448529/178435439-698f7af8-3ff3-440b-8b70-96274bff1eed.png)

Other errors cite FeatureFlagContext and AdminSubMenu. The state of the page changes multiple times automatically, without any interaction (probably because changes in Contexts propagate hierarchically...?)

Also, I noticed isblockedrepositoriesuienabled is queried two times per load.

☁️ As much as I love the "feature flag in context" approach: One way to move forward with this would be to do the feature flag it "as usual", and play around with the other approach separately. 💯

[andrew-farries]

@andrew-farries When loading /workspace I see a blank page in 50% of the cases, or errors like this:

The errors you were seeing were due to me using a telepresence pod at the same time that Werft deployed another dashboard pod to the preview environment. I had the same problem. I've stopped messing with telepresence so it should be good now.

[geropl]

nit: I feel this should be named "Blocked Repositories": That way it's not confused with other entities (User, Workspace, Repository).

[geropl]

Code LGTM, tested and works.

/hold because of names, names, names... #11304 (comment) 🙃

[andrew-farries]

Renamed and tagged in @gtsiolis because I made the submenu wider to accommodate the longer text.

@gtsiolis this width change 31b599f applies to all submenus, not just the admin one.

Looking at the other areas where a submenu is used it seems fine. We could alternatively pass the width as a prop to PageWithSubmenu.

[gtsiolis]

Looking at this now! 👀

Thanks for the ping, @andrew-farries! 🏓

[gtsiolis]

Thanks again for the ping, @andrew-farries! 🏓
Left one non-blocking comment regarding menu order. ❗

🍊 🍊 🍊 🍊

The subtle 16px change in the width of the sidebar sounds ok from UX perspective to leave as is for all sidebar instances, no need to introduce a prop for conditionally change the width. ✔️

This would also look ok even after replacing the sidebar menu with tabs for the admin dashboard #7879. ✔️

Long-term we can work of fine tuning breakpoints and column layout, see relevant discussion (internal) and some early designs around this in #8133 (comment). 🗺️

🍋 🍋 🍋 🍋

One aspect that is not clear but probably irrelevant and out of the scope of this PR at the moment is whether we'd like to also list repositories, introduce a repository view, and have an action to block from there. This could be relevant when we introduce better control for multi-repository support, etc.

🥝 🥝 🥝 🥝

Regarding the menu label, I agree with @geropl in #11304 (comment) on being more explicit here although the dashboard design so far has been using shorter verbs or labels when possible to be clearer to users but also follow our design principles (internal). 🥯

[andrew-farries]

/unhold