Allow system key to be managed in similar ways as host keys #4728

It would be nice if system keys for a function app:
1. Can be set to a user-provided value.
2. Can be renewed & revoked.
3. Can be managed through the portal.

1st feature is the one I care about the most.

Problem

I have two function apps (with same code) in two different azure regions. There is an Azure Front Door service that load balances the http traffic (REST api). Users from region A get directed to function app in region A, and users from region B get directed to function app in region B. Also, if one region is down, front door will direct traffic to other.
The app(s) also have a function with EventGrid trigger that does some background work. At present, I can either subscribe them both to events or only one. If I subscribe one, then my service is degraded if that region goes down. If I subscribe them both, then each event is received by both (redundant, but I would prefer to not have to deal with duplicate events).

It would be nice, if I was able to register the function app through it's front door url, and then front door can take care of routing. So if one of the two apps is down, front door takes care of routing it to the one that is up. If both are up, only one of gets a specific event, so no need to worry about duplicates.

However, it is currently not possible to subscribe such load balanced function apps via their front door url because each function app has a unique system key.

Solution

If the system key supports a user specified value (host keys support this), then I can configure both function apps with the same system key, and then front door can be easily used in front. For example, one can register below url as a webhook endpoint in event grid subscription:
https://<frontdoorurl>/runtime/webhooks/eventgrid?functionName={functionname}&code={mysystemkey}
Now, when the front door routes an event to any of the two apps, it still works because they share the same system key.

Alternative

For my particular case, one alternative is to use a HTTPTrigger function to handle events:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-event-grid#use-an-http-trigger-as-an-event-grid-trigger
However, this means I will have to write some boiler plate code that is not needed in EventGridTrigger functions (like managing subscription endpoint validation)