BL-1649 Add fluent ZipFile utility for compress, extract, and list ZIP archives

[franciscosierra1915]

Description

This pull request introduces a new fluent utility class ZipFile in the runtime.util package to support basic ZIP file operations.

The implementation follows the same fluent API pattern used by other utilities in the project (such as PropertyFile) by allowing method chaining through returning this.

The new ZipFile class provides the following functionality:

• compress() – Compresses a source file or directory into a .zip archive.
• extract() – Extracts a .zip archive into a destination directory.
• list() – Lists the contents of a .zip archive without extracting it.

The implementation uses Java's built-in java.util.zip package, specifically:

• ZipOutputStream
• ZipInputStream
• java.util.zip.ZipFile

Security protections were implemented to prevent ZIP Slip attacks by validating normalized paths during extraction.

Example usage:

new ZipFile()
    .source("myFolder")
    .to("archive.zip")
    .compress();

This feature introduces the foundation for fluent ZIP utilities in the runtime and follows the architectural and coding patterns already established in the project.

No external dependencies were added.

---

Jira Issues

Jira Issue:
BL-1649
https://ortussolutions.atlassian.net/browse/BL-1649

Bug Tracker:
https://ortussolutions.atlassian.net/browse/BL/issues

---

Type of change

• Bug Fix
• Improvement
• New Feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

---

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my feature works
• New and existing unit tests pass locally with my changes

[bdw429s]

Hi @franciscosierra1915 ! So, looking over this

• We want to be using our existing ZipUtil for all actual zip file manipulations, not creating any duplicate logic in the ZipFile class
• We don't want to be adding the testbox or tests folders to the repo. I looked through, but couldn't tell if you actually had any tests you had written in there. If so, we'll want to convert those to use our JUnit test suite which you can run via Gradle or VSCode
• If you look at how the propertyFile() feature is implemented, there is a ProperyFile.java BIF that is the entry point for it in the language, that delegates to the actual transient property file instance which has the fluent API. We'll want to do the same thing here, where we add a new zipFIle() BIF that is the entrypoint for the zip file object.

Most of our team is at a conference right now, but we can get on a call to discuss so we're all on the same page if you like.

[lmajano]

Overall, you need to cleanup this PR a lot.
There are tons of unecessary files that should not be here.

The ZipFile fluent class like @bdw429s said should follow the same pattern as the PropertyFile approach.

It starts from the entry point which are the Built In Functions (BIFS). Just like we have a PropertyFile BIF, we need a ZipFile BIF following the same pattern.

The ZipFile object should delegate to our ZipUtil for all operations.

[lmajano]

This File is only a fluent delegator. All the logic should be kept in the ZipUtil that exists already. Take a look at the PropertyFile for inspiration.

[lmajano]

Why is this here? This file doesn't belong here.
Also, testbox should NOT be committed to the repo.
Everything is already in cluded in the project in order to have dependencies and test.

Just run the gradle tests as per the contributing doc.

[lmajano]

Why is this here?

[lmajano]

Why is this here?

[lmajano]

Why is this here?

[lmajano]

Why is this here?

[lmajano]

@bdw429s you want to direct here since we have a BoxFile type now?