feat: Support requirements layer caching

[mLupine]

Closes #148.

Unfortunately, even though I managed to make the code generate the same layer zip file every time, JSZip always generates an archive that differs from the previous one by just a few bits. This is enough, however, to change the checksum of the generated archive and make Serverless reupload the layer archive despite no changes being made to Python dependencies.

So, instead of making the archive file look the same on every deploy, I took a different approach and made the plugin actually use the same archive on every deploy (unless requirements changed, of course). The plugin now generates the layer zip in the cache directory and creates a symlink to that file inside .serverless, resulting in shorter deployments times with no side effects.

[pgrzesik]

Hello @mLupine - thanks a lot for the PR. Do you happen to know why JSZip always creates differing archives? Also, could you please rebase your PR on top of current master? Thanks in advance 🙇

[mLupine]

Hi @pgrzesik, unfortunately, I didn't dig into JSZip deep enough to find out the cause of the problem. I only found this issue and it was enough to convince me that it was a problem with the library itself.

[pgrzesik]

Thanks a lot for providing more context @mLupine - I wonder if we could replace zipping library to something more deterministic, but that might increase the scope - I'm still getting up to speed on some of the parts of the plugin, I'll dive into the changes later this week

[mLupine]

While I fully agree that ZIP generation should be deterministic, I think that caching the generated file should be implemented in the library anyway.

Having the archive with the same SHA hash would speed up deployments from multiple machines (i.e. made by different team members), but having the ZIP already cached speeds up the deployment even more. With the changes from this PR, the plugin only checks if the file is present in the cache directory and skips the compression process completely. It's just a few seconds, but it actually makes the local deployments more smooth.

[mLupine]

Hi @pgrzesik, is there anything left to be done in this PR? I think it'd be great to have it merged as it greatly improves consecutive deployment times :)

[pgrzesik]

Thanks @mLupine and sorry for the delay, I was on vacations and just came back last Friday. The PR looks good to me, the only thing that needs to be kept in mind I guess is the fact that we're imposing that if there are no requirements.txt change then there's no change with actually resolved deps which not always will be the case (e.g. when versions are not strictly pinned) but I think it's okay in this situation.