refactor(zip): unify different methods for zipping project. (WIP)

[Hweinstock]

Problem

Both prepareRepoData and zipUtil are ways to take your current workspace and package it up as a zip. /doc and /dev use prepareRepoData. /review and /test use zipUtil. Their implementations are pretty similar and we should be able to have a shared utility that is a consolidated version of the two.

Both implementations are highly coupled to their use case, but more so zipUtil. Additionally, zipUtil uses admZip, a non-web compatible dependency.

GOAL

• Generalize project zipping functionality such that it lives in one place.
• Remove dependency on admZip in zipUtil.
• Increase testing coverage for the methods themselves, and for their components (by splitting them into testable components).
• Decouple zip utility from Q agents.

Solution

• move prepareRepoData tests to live in core module since thats where prepareRepoData lives. Do the same with zipUtil.
• [in progress...]

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Hweinstock]

/runIntegrationTests

[Hweinstock]

/runIntegrationTests

[jpinkney-aws]

Code is looking pretty good so far 🚀

FWIW for:

move prepareRepoData tests to live in core module since thats where prepareRepoData lives. Do the same with zipUtil.

those are probably eventually going to be moved back to amazon q anyways, once we deprecate the current implementation, since the only common thing between toolkit/q at that point will be maybe the lsp downloading?

[jpinkney-aws]

Whats the use case for the promise/non promise response vs just always returning a promise and then callers can either do await or void

[Hweinstock]

My understanding of the ZipStream code is that it will wait until all files are done streaming in the finalize step. Therefore the most common use case is to avoid awaiting the promises individually so that we aren't waiting on IO operations until all files are added. Its only the tests where we await these promises.

[jpinkney-aws]

Do you think it would be hard to eventually get rid of these useCase conditions?

[Hweinstock]

Yea, this is what I am struggling with now. These enums are everywhere in ZipUtil and make it difficult to pull out general components.

[Hweinstock]

those are probably eventually going to be moved back to amazon q anyways, once we deprecate the current implementation,

Once the agents live in flare, it can be removed completely right?

[Hweinstock]

Planning to scrap this work as the PR is becoming messy. The ZipUtil class needs to be heavily refactored and almost rewritten before it can be merged with prepareRepoData. The passing of use case enums makes it very difficult and risky in its current state to extract the general zipping logic. This is amplified by the lack of tests surrounding many important behaviors witnessed in this code making changes risky.

Current plan is to focus on decoupling ZipUtils from its consumers first. Once that can be done, the rest of the changes should follow more naturally and can potentially reuse ideas from the work here.