couple thoughts on serverless-offline, hapi update and websockets support

[dnalborczyk]

I was thinking about a couple things on how to move forward with the hapi updates to v18 #657 and the websockets support #674 and a bunch of other stuff, before any of it gets stale.

I'm suggesting to create a next branch (or any name for that matter), and release a major version, with breaking changes, alpha versions of current development.

current development would include:

in order to make the project more maintainable, I would remove the usage of context.done, context.fail, context.success. they are, as far as I understand essentially deprecated, at least in the docs https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html is no mention anymore. not sure how the API itself behaves. when I send in the memory leak fix PR, I wasn't aware of this context API, and all hell broke loose. If anyone is using an old unmaintained and deprecated node version, with the old context api, well, they can use an old serverless-offline version as well. although the serverless framework still supports it I believe at the moment, I don't think that serverless-offline has to follow suit.
more info: https://aws.amazon.com/blogs/compute/node-js-4-3-2-runtime-now-available-on-lambda/ and https://stackoverflow.com/questions/47906116/context-vs-callback-in-aws-lambda

I'd also try to remove, and simplify, the timeout functionality, which also caused quite a bit of trouble. I haven't looked into it, and there's also a // comment in the code (// We cannot use Hapijs's timeout feature because the logic above can take a significant time, so we implement it ourselves) for a possible hapi timeout functionality to use. I also wouldn't put too much emphasize on it, as a cold start of a lambda container adds execution (and therefore billing) time as well. I also don't think it needs to be THAT accurate, let alone it also depends on the hardware (aka memory) options. so simulating any of it is close to impossible.

we should also rebase and pull in the hapi v18 (#657) upgrade fairly soon, as it gets harder and harder, and more time consuming, to keep the PR in sync with master. there might be also some stuff breaking, which isn't covered by tests, as the code base has quite grown over time as far as I can tell.

then I'd rebase the PR for the support of websockets (#674), which still needs quite a bit of work I believe, although the preliminary heavy lifting was already done by @computerpunc and @triptec

BUT

an early alpha release, with possible breaking changes from above, would do no harm. people interested in giving it a try can give feedback. stuff can and will break. if it does, anyone can either pin a specific alpha version, or go back to latest. I think it's also easier to contribute to OSS, when it's being used at the same time, as it is VERY time consuming.

we should also pin an alpha feedback issue similar to what webpack does: https://github.com/webpack/webpack/issues to make people aware.

• cut next branch, release some alpha.x major version.
• only support node 8.x LTS and above, deprecate node 6.x LTS and below, as already done by Node Foundation and AWS Lambda.
  - [ ] remove said context functions.
• remove, and replace timeout functionality.
• rebase and pull in hapi v18 upgrade (which requires node v8+)
• pull in/rework websocket support PR, and keep adding stuff.
• meanwhile keep cleaning up whatever comes along.