Support configuring the paths to include in serverless.Functions

[lukehoban]

An aws.serverless.Function can now accept a list of include paths, which will be included inside the Lambda package along with the generated __index.js file

Also changes the default from '.' to './node_modules', so that the very common case of changes to the root folder do not trigger changes to the code for lambdas. If files from the local folder are needed by the lambda, they can be included in the includePaths parameter.

Also adds support for providing a pre-created Role instead of just Policies, to support scenarios where users want to pre-create or share a Role across multiple functions.

Part of #35.

[lukehoban]

Merging, but happy to address any feedback in follow-up. @CyrusNajmabadi @pgavlin.

[pgavlin]

🙌

My only feedback is that it'd be nice to have an excludePaths option as well s.t. only paths in includePaths that are not under paths in excludePaths are included. This would e.g. allow me to include all of node_modules except @pulumi and grpc without needing to do anything terribly fancy. As it stands, I could do this via a filtered ls on node_modules, but it'd be nice to avoid even that.

[joeduffy]

I have to admit, I don't understand our end game for this work. We seem to be moving in a direction of treating each lambda as though it is its own distinct "application," and I have a hard time keeping track in my head what will work and what will not work. For instance, I fear the simple case of

import * as routes from "../app/routes";
import {HttpEndpoint} from "@pulumi/cloud";

const api = new HttpEndpoint();
api.get("/", routes.index);
api.post("/customer", routes.createCustomer);
// ...

will now stop working, because I can't possibly know the full transitive set of imports those routes will need. It's just not clear yet to me how this will surface in the @pulumi/cloud layer -- but I may be missing something -- and I fear that the compositional properties will be difficult to predict. For instance, imagine that I'm creating a lambda that is separated by 10 callframes from the library code that actually news up the serverless function object, and I want to do a relative import of some file. Do I now pass a list of files along with the lambda? Or are we creating a first class cloud.Function object?

This is more like how most other solutions treat lambdas, but this is a place where Pulumi has historically intentionally been different. We encourage people to mix runtime and infrastructure code freely. I worry that us not letting you share imports, plus not even easily sharing files, will mix poorly with the fact that we're encouraging you to put all your code into shared files.

In short, either there's something I'm just completely misunderstanding about where we think all of this will settle, or I'm increasingly nervous about continuing in this direction.

[CyrusNajmabadi]

Awesome. Thanks for doing this.