fix internal Serverless custom resources S3 path addressing

[bentsku]

While debugging a support case about serverless-python-requirements, I stumbled upon an issue regarding Serverless own internal Custom Resources: they would spin up a lambda to update the notification configuration of an existing S3 bucket. However, they would try to access it using virtual host addressing, leading to the lambda failing and the bucket not getting the right configuration. You can reproduce it using this kind of function events:

functions:
  s3_to_dynamodb:
    handler: lambda_functions/s3_to_dynamodb.lambda_handler
    events:
      - s3:
          bucket: test-bucket
          event: s3:ObjectCreated:*
          rules:
            - suffix: .csv
          existing: true

The deployment would not fail, but the S3 bucket would not trigger the lambda.

This PR introduces a mechanism to hook into package:compileEvents which is triggered when building resources to manage events. We're checking for the presence of the custom-resources.zip file, which would be created if Serverless was going to package its internal custom-resources to create its lambdas.
We then get the utils.js file which is imported by all lambdas, and set the SDK config there to use S3forcePathStyle=true.
As there are nothing in the node standard library to unzip file, I had to introduce a new dependency, adm-zip.

Relevant documentation:

• Lifecycle Events - Serverless : https://www.serverless.com/framework/docs/guides/plugins/creating-plugins#lifecycle-events
• Every lifecycle listed: https://gist.github.com/HyperBrain/50d38027a8f57778d5b0f135d80ea406
• adm-zip: https://github.com/cthackers/adm-zip
• adm-zip on DigitalOcean: https://www.digitalocean.com/community/tutorials/how-to-work-with-zip-files-in-node-js

[whummer]

Awesome set of changes, very clean and nice solution with the package:compileEvents hook and overwriting the zip archive. 🚀

Over time, we may be able to fix this in the Lambda runtime itself (DNS project, transparent endpoint injection). But this is a great workaround for now.

For the record: Interestingly, I wasn't able to replicate the error on my side (on MacOS). Tried different combinations of host/Docker mode, community/ext, and old/new Lambda provider. Didn't seem to be able to replicate the Inaccessible host: drop-bucket.172.17.0.2\' at port undefined error.. In any case, the changes LGTM, and was able to replicate the behavior of the zip packaging of the patched utils.js locally. 👍