Implement basic subscription feature

[mthenw]

It should allow attaching an event to a function.

It can be implemented as a part of function discovery, where during the function registration source events can be defined

Example:

{
	"id": "welcome-email",
	"instances":[{
		"provider": "aws-lambda",
		"originId": "arn:aws:lambda:us-east-1...",
		"region": "us-east-1"
	}],
        "events": [{
            "id": "userCreated",
            "retry": false
            ...
        }]
}

or as a separate endpoint POST /subscriptions

Example:

{
    "functionId": "welcome-email",
    "eventId": "userCreated",
    "retry": false
    ...
}

retry is an example field. I should start with something simple, at-least-once delivery semantic.

[spacejam]

I have some serious concerns about trying to reconcile state between the platform and this system. I'd like to talk with you and @nikgraf on tuesday to make the case for unified configuration storage, which will negate the need to have multiple API's that effectively act as a pass-through that may fail, either forcing the platform caller to be much more complex as it handles infinite retry (and backpressure to ensure that it doesn't accumulate too many pending updates while the gateway data store is down), or destroying the consistency of the overall system.

[austencollins]

Will http requests use this and be considered an event like everything else?

[spacejam]

We should be able to specify that the input to a function is an event, as well as its output. The gateway will sit on both sides, and can asynchronously pass it along.

[spacejam]

We should allow multiple function inputs/outputs to be forwarded to a topic. Then functions subscribe to that topic, instead of just another function's input or output. By decoupling specific functions from topics, we can more easily support migrations and make reconfigurations easier.

[mthenw]

#60