Add ASP.NET Core WebHooks support (issue #5)

[dougbu]

This approach is more ASP.NET Core-native than #152.

Users write controller actions annotated with (say) [GitHubWebHookAction] instead of WebHookHandlers. Dispatching between multiple handlers must be done manually though we could add abstract controller base classes which dispatch to handlers in the old way.

Those developing new receivers can start from WebHookReceiver though the subclasses should also implement IResourceFilter or IAsyncResourceFilter. This improves modularity and allows base WebHook...Filters for most needs.

[dnfclas]

@dougbu, Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request. Thanks, .NET Foundation Pull Request Bot

[Havret]

What is the status of this PR? Can I safely try to use it?

[dougbu]

@Havret our team feels the general approach is sound but we have not yet reviewed the details of this PR. Feel free to test it out but I would not recommend call it a perfect indicator of the APIs we'll ship. Put another way, treat dougbu/add.core.II as a proposed feature branch with more changes expected.

Note the Core Trello and WordPress receivers are currently almost-empty projects. Core Custom, Generic, Instagram, MyGet, VSTS, and Zendesk receivers do not yet exist; neither does anything on the sender side (no Microsoft.AspNetCore.WebHooks.Custom…).

Please let us know if you experience any problems!

---

For those of you used to the WebHooks 1.0.0 approach:

• Receiver names shouldn’t have changed
• Configuration settings names and formats shouldn’t have changed though web.config isn’t relevant anymore
  • best set as Azure application settings, environment variables, or in appsettings.json
• Handlers are now ASP.NET Core MVC action methods with [GitHubWebHook] attributes (or whichever receiver you choose)
  • check the attribute documentation comments for supported action parameters; names are important here because binding is convention-based
  • A number of receivers do not support binding event names but KuduConstants (or whichever) and IFormCollection, JObject, and XElement action parameters make it pretty each to grab the information from request bodies
• Receivers are now a bundle of metadata-driven MVC application models, constraints, and filters that are (mostly) enabled globally but no-op for receivers that don’t use them
  • configure a receiver in your Startup.ConfigureServices(…) method with services.AddMvcCore().AddAzureAlertWebHooks(); (or whichever)

[dougbu]

@Havret I'm not sure what you mean. The branch contains a fair number of different Core receivers as well as sample ASP.NET Core MVC applications using them. Could you clarify your question?

[Havret]

@dougbu What's missing is the example how to configure custom receiver which can consume events send by old asp.net publisher. It would be great if you can add something like that. Because lack of documentation I'm having problems with picking up the pieces. Cheers.

[dougbu]

Rebased on dougbu/stripe.event.data.154 and removed changes covered in #161. Now includes Stripe support in Core receiver and command-line builds are clean.

[dougbu]

:up::date: to reduce number of commits

[JDL440]

Is .NET Core 1.0 a possibility?

[dougbu]

@JDL440 this PR targets .NET Core 2.0. What drives your 1.0 request?

[JDL440]

My service targets 1.0 currently and I'm investigating add webhook subscriptions.

[dougbu]

@JDL440 please file a separate issue in this repo so that we can track the idea of re-targeting the new ASP.NET Core support.

Another issue, perhaps filed at https://github.com/aspnet/Home, may help us understand anything blocking migrating your service to .NET Core 2.0. For example, is the documentation at https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/ insufficient in some way?

[dougbu]

5f62336 got this in because it's too big to review. Will address any issues in follow-up PRs.