Revamp CKAN triggers

[HebaruSan]

Motivation

SpaceDock notifies CKAN of mod creation and updates if the uploader checks the CKAN checkbox. Currently a lot of this logic is owned by SpaceDock:

• For creation, a pull request is submitted for NetKAN
• For updates, the NetKAN repo is searched for matching $krefs and then a request is sent to the NetKAN /inflate web hook to process them

This is more CKAN implementation detail than SpaceDock ought to have to be aware of. SpaceDock should really only have to tell CKAN, hey, we have this event for this mod, and CKAN should figure out the rest.

Changes

NOTE: This change depends on KSP-CKAN/NetKAN-Infra#130! The format of the /sd/add hook was wrong in the initial implementation, and this PR assumes that that other PR has been merged.

The CKAN team has been rewriting our web hooks, and as part of that we've created two new ones to replace this logic:

• /sd/add - Receives info about a mod and makes a pull request in NetKAN, just like before but now owned by CKAN
• /sd/inflate- Receives info about a mod and submits it to the inflation queue, again just as before but owned by CKAN

This pull request updates SpaceDock to use these new web hooks, simplifying the SpaceDock side of things significantly. The https://github.com/KSP-SpaceDock/SpaceDock-Notify repo can now be retired.

Make the following changes to config.ini after merge:

# URL to notify of mod creation
create-url=https://netkan.ksp-ckan.space/sd/add

# URL to notify of mod updates
notify-url=https://netkan.ksp-ckan.space/sd/inflate

Fixes #232.

[DasSkelett]

Should we really include the webhook urls in the example config?
I mean they are firewalled for sure, but everyone setting up a local dev env for SpaceDock will have them included in his config.ini and automatically doing requests to these urls when testing.

[HebaruSan]

Should we really include the webhook urls in the example config?

Good point. Removed that and added it to the PR description instead.