feat(LMP-6728): patch memory leak in serverless-esbuild fork

[Ilya-Meer]

• feat(LMP-6728): initial commit to align fork with our process
• fix(LMP-6728): patch bundle file to remove memory leak

Overview

This PR is an attempt to resolve our monorepo build issues stemming from a memory leak in serverless-esbuild. With this patch, suggested in the Github thread, memory consumption should go back to normal.

This PR also removes some extraneous files from the upstream and brings the repo more in line with our process of doing things.

Key Changes

Checklist

• Commits are atomic
• Code aligns with the developer handbook guidelines
• Documentation has been updated if necessary

[gregholland]

This PR also removes some extraneous files from the upstream and brings the repo more in line with our process of doing things.

What's the thought process behind this? I don't think this is necessary, here's my reasoning:

• The goal, if this fix works is to submit a PR upstream to fix the problem, then go back to using the OG version, not our fork. We should use their commit style, and leave things as is.
• It's going to be a challenge to ever pull in upstream changes now that we've diverged
• The hope is this isn't something we're taking over and maintaining ourselves.

You actual fix itself seems fine, although I'm not familiar with the problem.

[Ilya-Meer]

This PR also removes some extraneous files from the upstream and brings the repo more in line with our process of doing things.

What's the thought process behind this? I don't think this is necessary, here's my reasoning:

• The goal, if this fix works is to submit a PR upstream to fix the problem, then go back to using the OG version, not our fork. We should use their commit style, and leave things as is.
• It's going to be a challenge to ever pull in upstream changes now that we've diverged
• The hope is this isn't something we're taking over and maintaining ourselves.

You actual fix itself seems fine, although I'm not familiar with the problem.

@gregholland Okay, no problem, I can remove all the changes other than the patch. Getting this merged into the upstream is going to be challenging because I'm not familiar with the project either so I need to first test if this fix works, then if it does, make sure that it conforms with the upstream's code style, other functionality, get tests running locally, add test cases etc. To me that is less of a priority than solving our specific problem, which we can do without doing all of that work.

I don't want to maintain this fork, and I also don't want to spend cycles on intimately familiarizing myself with someone else's project especially if the plan is to move off of Serverless v3 in the first place