feature requests - lambda node runtime, custom lambda function, and custom policy generation

[des-des]

First of all thanks for building this. All my logs are now happily moving into my elasticsearch cluster :)

I had to fork this to make it work, I thought I would outline my changes, and why, and then you can see if you would be interested in me making a pull request

Problem 1 - policy size

Right now, beyond a certain number of lambdas, then will fail to deploy, since the policy on the ingestion lambda becomes too big.

• my solution - https://github.com/edyncare/serverless-es-logs/blob/master/src/index.ts#L252-L266 , I wildcard the arn
• potential solution for serverless-es-logs - I do not have any experience with serverless, so I am not sure if all the lambdas deployed in a particular stage have a common prefix, or if we can get the prefix, but if it is possible that would be my suggestion

Problem 2 - lambda runtime version

we have everything on 12.x, it would be nice to be able to configure the runtime version of the lambda deployed by this package.
why we are setting a node_options flag that is not available in node 10, so the lambda could not start,

Problem 3 - incompatible with latest elastic search

I am not quite sure about this one, but I think this line https://github.com/daniel-cottone/serverless-es-logs/blob/master/templates/code/logsToEs.js#L124 is problematic. https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html
We could also allow an optional es version in the config to configure this. But I feel like at some point I will want to go in and modify that lambda anyway, so potentially giving users to define their own lambda might be a more flexible solution

Please let me know if you would like a pull request on any of the above. Again, thanks for putting this together :)

[daniel-cottone]

Thanks for the feedback @des-des! Regarding your issues:

1. If policy size becomes too large, one current workaround you could make is to use the default role. I don't think that making the arn wildcard by default is a great solution, since being very specific with access is best practice. Not sure what the best solution would be but I am open to suggestion.
2. I think we just need to upgrade the default lambda runtime version rather than making this configurable.
3. I am not sure about this one. I'll have to investigate or, if you could, provide some more details of what specifically is breaking.

I think that you should break these up into different issues rather than lumping them together, if you still feel each one warrants an issue.