functions: common concurrency stream for sync and async

[ucirello]

This is a proposal that addresses concerns some aspects of #165 and #69.

1 - We have now a supervised goroutine that spawns workers for the incoming load. They serve any kind of request, sync or async (#165)

2 - Because runners start are separate from request life-cycle, we would be a third way closer to have hot reusable containers (#69)

Edit:
Implementation Details

This PR introduces new goroutine responsible solely for executing tasks. It interfaces with the HTTP server and async modules through a channel, whose contents holds both the task information, and a channel to send the answer backer to the caller. https://github.com/iron-io/functions/blob/bounded-concurrency/api/server/runner.go#L183-L188 and https://github.com/iron-io/functions/blob/bounded-concurrency/api/runner/async_runner.go#L142-L145

In order to prevent resource starvation between competing sync and async tasks, we reserve a maxium of 50% of the memory for async tasks. This number is arbitrary and might be subject to changes later. https://github.com/iron-io/functions/blob/bounded-concurrency/api/runner/runner.go#L118-L123

In practice, when the memory allocated for async workers is maxed out, it keeps looping until memory is available: https://github.com/iron-io/functions/blob/bounded-concurrency/api/runner/async_runner.go#L117-L121

Also relevant is that Server now fathers handleRequest https://github.com/iron-io/functions/blob/bounded-concurrency/api/server/runner.go#L37 - with which it injects the tasks channel into the HTTP server.

[treeder]

Couple questions @ccirello:

• The work done in Wait for capacity if no RAM left on server and log wait time as metric to logs #10 should have made it bound to the max number of runners, with a small buffer (100 requests), then the rest get rejected. Unless that didn't get implemented like the issue description? cc @pedronasser
• What's the point of resizing the number of runners? There's always some fixed limit to the memory available right at the start. We can't go above it and there's no loss for keeping them running when below.

[ucirello]

@treeder now that I have the information that the runner regulates itself, there's no need for max runners. I am going to remove this extra mechanism.

[pedronasser]

LGTM