lazy load unused lambda packages in core

[kyeotic]

NOTE: #2278 was the orignal PR, which I screwed up with a rebase. Im reopening because my git-fu is insufficent to fix it.

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests (NA)
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

This is to address loading time issues raised in #2162

There are three changes of note.

1. In lambda-server-core I moved the subscriptions-transport-ws and apollo-engine-reporting into lazy-loaded requires and changed the top-level imports to just import the type. Since lambda's cannot take advantage of these packages, loading them is pure cost. I didn't see any other type-only imports to style after, so I followed the handbook convention of underscore-prefix-capitalized.
2. I had the util.promisify polyfill check the node version before loading itself. NOTE: there are already tests in node 6 and node 8 that exercise this code
3. this is a hack I added an ENV VAR check into runtimeSupportsUploads() that looks for AWS_EXECUTION_ENV, which the lambda runtime sets. This checks stop the import of apollo-upload from occuring. The library is unfortunately a top-level import, so moving it anywhere that apollo-server-lambda could have controlled directly without changing the contract was impossible. A better solution probably exists that does not hack its way through process.env. The best solution would be removing apollo-upload from the core entirely, since it surely does not belong there.

These changes combine to reduce the cold-start time of a 512mb AWS Lambda from ~450ms to ~250ms.

Before

After

(Yes, the flame graph has a rendering bug, but the numbers are accurate)

512 is a pretty beefy lambda for node, 256 is more common. These effect will be amplified the lower memory you go, because AWS matches the CPU to the allocated memory. If it is necessary, I can re-run these performance profiling on smaller lambdas.

[kyeotic]

@abernix @martijnwalraven really hoping to get this looked at, its a non-breaking change with a significant performance improvement

[pierreis]

Awesome work.

Really looking forward to see that one merged ASAP.
For now, defaulting to excluding packages in webpack, but this is far from ideal. The difference in bundle size as well as cold start time is significant.

[kyeotic]

@pierreis Maybe try adding a 👍, I'm not really sure what I need to do to get the maintainers to look at this. I've given up rebasing until one of them responds

[pierreis]

Done.
@martijnwalraven @abernix : any thoughts about the steps to get this merged?

[kyeotic]

@martijnwalraven @abernix Its been a few months. Is there something I can do to help move this forward?

[holmankb]

+1 Would be great to see this merged in.

[abernix]

I really appreciate you opening this PR, and it demonstrates very clearly how important it is that we always consider the dependency tree anytime we introduce any new downstream dependencies, particularly since Apollo Server runs in so many different environments, some of which are particularly sensitive to the additional cost of extensive module resolution (and other times, just because certain modules are not compatible with all environments!)

The work in this PR was mostly also implemented by #2305, #2304 and #2054, but the remaining subscriptions-transport-ws and unnecessary util.promisify imports are still super worth addressing. So, thank you!

I've made a couple tweaks, but will cut this into the next 2.6.0 alpha release!