Delete obsolete WebhookRouter tool

[konrad-jamrozik]

This PR deletes obsolete WebhookRouter tool, per this comment: #4937 (review)

Once this PR is merged, I will also delete the internal / tools webhook-router pipeline.

@hallipr this PR requires your approval per the comment linked above.

Question to all reviewers: Should I reclaim anything from the deleted directory? E.g. the New-AzureDevOpsRuleCredentials.ps1 script?

[benbp]

I think it's ok to delete those scripts, even if they may contain some secret devops magic we may need to re-discover in the future.

[weshaggard]

I defer to @benbp and @hallipr on whether or not we need this any longer.

[konrad-jamrozik]

@benbp @hallipr I ran in Application Insights this query, for last 7 days:

traces
| where message startswith "Sending event from route" or message startswith "Sent event from route"
| summarize count() by message

(sources for the messages here, in tools/webhook-router/Azure.Sdk.Tools.WebhookRouter/Routing/Router.cs)

and found this:

message	count_
Sent event from route (cut) to namespace checkenforcerprod with hub name github-webhooks	15863
Sending event from route (cut) to namespace checkenforcerprod with hub name github-webhooks	15863
Sending event from route (cut) to namespace issuelabeler with hub name issue-labeler	1602
Sending event from route (cut) to namespace githubwebhooks with hub name githubwebhooks	2934
Sent event from route (cut) to namespace githubwebhooks with hub name githubwebhooks	2934
Sent event from route (cut) to namespace issuelabeler with hub name issue-labeler	1602

which gives us a list of recipients that possibly do something with these webhook events.

I did find checkenforcerprod and issuelabeler Event Hubs Namespaces in Azure SDK Engineering System subscription and githubwebhooks in Azure SDK Developer Playground subscription.

I could dig deeper and try to figure out what happens with these events downstream. But I am curious if you have some additional insights based on this data.

[konrad-jamrozik]

Per discussion with @hallipr on Teams:

• we should wind down the consumers of the routed messages before decommissioning the router itself
• additional insight: checkenforcerstaging hasn't had any outgoing messages in the last 30 days, but checkenforcerprod has, per investigation above

[konrad-jamrozik]

I am closing this PR for now, as there is more work to be done before we can decommission the tool. I captured our findings and work required here:

• Decommission all WebhookRouter tool downstream consumers and then the tool itself #4992

Once the prerequisite work is done, we can re-open this PR.