feat: introduce temporary admin mode for site config

[dcshzj]

Problem

Ops load on engineers is quite high for editing the site config, navbar and footer.

Solution

Breaking Changes

• Yes - this PR contains breaking changes
• No - this PR is backwards compatible

Features:

• Add a new /admin route for Isomer Admins to directly modify the site's config, theme, navbar and footer items.
  • Access to this feature is gated for just Isomer Admins, all other users will not know of its existence and even if they do, they will not have the permission to access the form to edit.

Before & After Screenshots

View for Isomer Admins:

View for unauthorised users:

Tests

• Log in to Studio as a whitelisted Isomer Admin (your email should be whitelisted inside Growthbook).
• Go to any site.
• Verify that a star icon appears on the navigation bar on the left side.
• Click on the star icon, verify that you are able to see the form to change the site configurations.
• Change any configuration and save, verify that you are able to save successfully.
• Navigate to any page and verify that those changes have persisted (or change another configuration that is more visible, such as the navigation bar or footer).
• Log in to Studio as a non-whitelisted user.
• Go to any site, verify that there are only 2 icons on the navigation bar on the left side.
• Append /admin to the URL and navigate to the page.
• Verify that the page shows that you do not have permission to access the page.

[datadog-opengovsg]

Datadog Report

Branch report: feat/site-config-admin
Commit report: 13c7e02
Test service: isomer-studio

✅ 0 Failed, 266 Passed, 36 Skipped, 48.73s Total Time
➡️ Test Sessions change in coverage: 1 no change

missed something oopsie

[seaerchin]

minor issue - not too sure what the useEffect is doing! i think because this affects end user sites (and the site wide config), we might want to sanitise the json object to make sure it's valid (cos we're just parsing to make sure it's valid json, but not that the jsonobject matches what we expect - eg: {siteNavItems: [...]} vs {siteNavItem: [...]}

but no actionable re: the second point of matching - onlyi want to make sure the useEffect isn't sussy

[seaerchin]

mostly lgtm - i think blind spots for me are the useEffect, which is actually pretty confusing

the router method can be updated but not a real blocker, given that it's narrowly used and easy to infer from context