[WebJobs][EventGrid] Support Cloud Events in EventGrid WebJobs Extensions

[ellismg]

There are a few moving pieces here:

• For the trigger binding, the handshake between the service and the listener when creating a subscription is different. Instead of sending a "SubscriptionValidationEvent" and expecting a certain response object, the service instead follows a different handshake where an OPTIONS request is sent to the underlying webhook (see: https://github.com/cloudevents/spec/blob/1085aeee96d0efd625dd1654a625064fde4be6ac/http-webhook.md#41-validation-request)
• The trigger will need to handle deserializing the event payload into the Cloud Event model type.
• Output binding will need to accept CloudEvent model types as well.

[ellismg]

/cc @pakrym . I should be able to handle this next milestone (for the November release)

[ellismg]

Spoke with @JoshLove-msft who's been maintaining the EventGrid trigger. We've made some progress here but we might have not done the first bullet so it may not be possible right now to set a function as a target for a subscription of cloud events. He's going to take a look - but that's likely the only gap left.

[JoshLove-msft]

Beyond the subscription validation handling, you currently cannot create a CloudEventSchema event subscription for an Azure Function.

[Expecho]

@JoshLove-msft

Beyond the subscription validation handling, you currently cannot create a CloudEventSchema event subscription for an Azure Function.

Does that mean it will be available some time?

[JoshLove-msft]

@JoshLove-msft

Beyond the subscription validation handling, you currently cannot create a CloudEventSchema event subscription for an Azure Function.

Does that mean it will be available some time?

That is the goal, but we don't have a definite timeline yet.

[JoshLove-msft]

• For the trigger binding, the handshake between the service and the listener when creating a subscription is different. Instead of sending a "SubscriptionValidationEvent" and expecting a certain response object, the service instead follows a different handshake where an OPTIONS request is sent to the underlying webhook (see: https://github.com/cloudevents/spec/blob/1085aeee96d0efd625dd1654a625064fde4be6ac/http-webhook.md#41-validation-request)

This turned out to not be the case. There is special handling in the service for the handshake when the subscription is using Azure Functions. In this case it uses the same HttpPostChallenge mechanism as for EventGridSchema since users wouldn't need to interact with this flow in general. However, there were issues in the format of how the CloudEvent HttpPostChallenge is delivered that required fixes.