Generic Webhook is too limiting to be useful/differentiated from HTTP trigger

In investigating working with Functions with other providers, I've come across a few scenarios where the API provider has a webhook strategy that is both a GET/POST implementation (GET issues a challenge first, then upon successful challenge, they POST the data). In doing this I chose initially to use the generic webhook trigger, but realized this wasn't going to work as this is a POST-only policy and validates application/json.

This seems like an arbitrary limitation. Webhooks in the industry don't define that it is a POST-only world, yet we are defining that in a policy-driven way with something called 'generic webhook' which seems wrong. When faced with these, this appears the recommendation is to use HTTP trigger anyway in these scenarios, thus not making the great case for Generic Webhook to exist.

Recommendation: let's remove (or fix) the Generic Webhook pattern here to be more flexible or remove it and go all-in on HTTP trigger being *the* way to interact with webhooks in the wild.