Reorganize repo

We currently just have the folder "extensions" inside of our repo which contains 40 different folders, each one for a different piece of content (extension/example).

However, it turns out that 30 of these are actually published, while 10 are in development but may not end up being published anyways.

In order to make it easier for anyone to navigate the repo, as well as potentially avoid failing tests on things we won't even publish anyways (see #376 , there was a problem where reaper was failing tests and we had to go back and explicitly exclude it, but honestly it never should have been included in the first place since we likely won't publish reaper anyways), we need to find a better way to organize it.

Recommendation: Align on which of the 10 pieces of content in development we want to drop. Delete them from the repo. Move the remaining pieces of content that we do plan to work on into connect-staging-extensions.

Note: for now, here are four we know we want to keep (so we can move them into connect-staging-extensions, then work on them there before moving back to connect-extension for publishing):

• audit-api
• oauth-integration-debug
• oauth-integration-validator
• integration-session-manager

We know we want to delete reaper.

We are still deciding on the remaining five:

• audit-reports
• datadog-prometheus-metrics
• notifier
• prototype-content-with-issues-table
• sdk-assistant

Recommendation: I recommend that we delete audit-reports, datadog-prometheus-metrics, and sdk-assistant. Move prototype-content-with-issues-table and notifier into connect-staging-extensions.

• Work on notifier so that it watches Connect's audit log and sends webhook alerts (e.g. to Slack/Teams/PagerDuty) on the events that an admin cares about (deploys, permission changes, failed logins). This would make it a reusable, configurable alerting template rather than just checking who deployed in the last hour (what it does currently). Then we can move it back to connect-extensions to publish.
• Take the functionality of prototype-content-with-issues-table (surfaces content whose latest deployment/job has failed) and fold it into content-health-monitor (an extension that is currently published), so that content-health-monitor becomes a single scheduled content-health report covering both content/URL uptime (that's what content-health-monitor does now) and failed deployments/jobs (that's what prototype-content-with-issues-table does now). It would overall become one report that tells you what content needs your attention. Then we can delete prototype-content-with-issues-table. As a side note, we could also roll a third prong into the new-and-improved content-health-monitor: surfacing orphaned content (content owned by deactivated/departed users or that's been unused/unviewed for a long time).

Start by inventorying the 40 directories under extensions and comparing their current test and publication behavior, including the failure described in #376. Review the proposed staging locations connect-staging-extensions and connect-extensions, then resolve which development extensions to keep or delete. Done means the agreed directories are moved or removed and the repository tests no longer include discarded content.