Remove submodules and adjust Dockerfile to no submodules setup

[razvand]

Remove submodules. We store all modules in the same directory, without submodules. We reference them as ../<module-name>.

Adjust the Dockerfile to missing submodules. The contents of Zeratool are located in ../zeratool_lib.

[Copilot]

Pull request overview

This PR updates the repository to stop using Git submodules and adjusts the Zeratool-lib Docker build to work with a “sibling modules in parent directory” layout (e.g., ../zeratool_lib).

Changes:

• Removed Git submodule configuration (.gitmodules).
• Updated docker/Dockerfile.zeratool_lib COPY paths to match a parent-directory build context and local zeratool_lib folder.
• Updated README build command to use .. as the Docker build context.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

File	Description
README.md	Updates Docker build instructions to use the parent directory as build context.
docker/Dockerfile.zeratool_lib	Adjusts COPY sources for the no-submodules layout and dependency handling.
.gitmodules	Removes submodule declarations (commons, zeratool_lib).

Suppressed comments (1)

docker/Dockerfile.zeratool_lib:46

• COPY ./automatic_exploit_generation/docker/protobuf /protobuf points to a path that doesn’t exist in this repository (there is no docker/protobuf directory). This will make docker build fail and also breaks the service’s import exploit_pb2/import exploit_pb2_grpc expectations.

COPY ./automatic_exploit_generation/docker/protobuf /protobuf

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docker/Dockerfile.zeratool_lib:29

• The image still sets PYTHONPATH to include /commons, but the Dockerfile no longer clones or copies the commons sources into the image. This will break imports like from commons... at runtime (and may also break dependency conversion if commons is referenced as a path dependency). Add a COPY for commons from the build context.

# Set PYTHONPATH
ENV PYTHONPATH=/zeratool_lib/zeratool_lib:/protobuf:/automatic_exploit_generation:/commons

# Copies service's dependencies
COPY ./automatic_exploit_generation/docker/requirements.txt /requirements.service.txt

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (4)

README.md:78

• The build instructions now use .. as the Docker build context, which will send the entire parent directory to the Docker daemon (potentially large) and the README doesn’t mention the required adjacent directory layout (../commons and ../zeratool_lib). This can cause slow builds and confusing failures if those directories aren’t present.

1. Build the Docker image: 

   ```console
        docker build --tag zeratool_lib -f docker/Dockerfile.zeratool_lib ..

**docker/Dockerfile.zeratool_lib:16**
* `COPY ./commons /commons` hardcodes the expected sibling directory name in the build context. If the commons repo is checked out under a different folder name, the image build will fail; using an `ARG` makes this portable without changing the default behavior.

Copy commons

COPY ./commons /commons

**docker/Dockerfile.zeratool_lib:35**
* The Dockerfile now hardcodes the module directory name (`./automatic_exploit_generation/...`) inside the build context. This makes `docker build` brittle (it fails if the repo is checked out into a differently named folder). Consider parameterizing the module root with an `ARG` and using it for all related `COPY` paths.

Copies service's dependencies

COPY ./automatic_exploit_generation/docker/requirements.txt /requirements.service.txt

Convert module's dependencies

COPY ./automatic_exploit_generation/pyproject.toml /pyproject.toml

**docker/Dockerfile.zeratool_lib:12**
* `COPY ./zeratool_lib ...` assumes a fixed directory name in the build context. Since the context is now the parent directory, the build will fail if the sibling folder has a different name/location. Making this configurable via an `ARG` keeps the Dockerfile usable across different checkouts/layouts.

This issue also appears in the following locations of the same file:
- line 15
- line 31

Convert Zeratool's dependencies

COPY ./zeratool_lib /zeratool_lib
RUN python3 /convert.py --no-version /zeratool_lib

</details>

[AmaliaI12]

Tested it and it works as expected. LGTM

[ClaraStefania]

Everything works as expected.