Support for Internal Networking Between Sidecars and Microservices with Configurable Host Networking

## Objective
Enhance the compose tool to support **internal networking** between sidecars and microservices defined in Helm charts. Introduce **configurable host networking** to allow users to toggle between Docker's default bridge network and host networking. This feature improves compatibility with Helm charts that rely on sidecar patterns, microservice interactions, logging agents, monitoring sidecars, or service meshes.

---

## Proposed Implementation

### 1. Parsing
- Identify **sidecar** and **microservice** containers in Helm-rendered Kubernetes manifests.
- Capture **networking requirements** such as ports and service discovery.

### 2. Networking Translation
- Map Kubernetes **pod-internal networking** (localhost communication) to Docker Compose's **bridge network**.
- Ensure sidecars and microservices communicate via **container names or aliases**.
- Create a **dedicated Docker network** for each Helm chart’s pod-like group to mimic Kubernetes pod networking.

### 3. Host Networking Option
- Add a CLI flag: `--enable-host-networking`.
- Configure services to use `network_mode: host` in the generated `docker-compose.yaml`.
- Ensure **port mappings** align with the host’s network stack, bypassing Docker NAT.

### 4. Service Discovery
- Implement **service discovery** within Docker Compose networks using **container names** or **DNS aliases**, replicating Kubernetes service behavior.

### 5. Configuration Options
- Enable/disable host networking **per service**.
- Specify **custom network names** or reuse existing Docker networks.
- Configure **port mappings** for sidecars and microservices.

---

## Challenges

### 1. Networking Isolation
- Kubernetes pods provide inherent isolation.
- Docker Compose bridge networks may complicate traffic isolation between unrelated services.

### 2. Host Networking Limitations
- Bypasses Docker’s network stack → potential **port conflicts**.
- Not fully supported on **macOS/Windows Docker Desktop**.
- **Security risks**: direct host network access.

### 3. Service Discovery
- Replicating Kubernetes DNS-based service discovery requires **careful container naming** and network aliases.
- Complexity grows with **dynamic or large Helm charts**.

### 4. Performance Overhead
- Creating dedicated Docker networks per pod-like group increases resource usage.

### 5. Compatibility
- Ensure consistent behavior across **Docker** and **Podman**.
- Podman networking differs (rootless containers, CNI plugins).

### 6. Port Management
- Sidecars and microservices may need **dynamic port allocation**, which can conflict with host networking or other services.

---

## Benefits
- Seamless communication between sidecars and microservices.
- Supports complex Helm patterns like **service meshes** or **logging agents**.
- Flexibility for **host networking** to access host-local services or reduce latency.
- Improves Helm chart compatibility with Docker Compose.
- Simplifies **debugging and monitoring** by aligning with Docker networking model.

---

## Acceptance Criteria
- Convert Helm charts with sidecars and microservices to a **functional docker-compose.yaml**.
- Sidecars and microservices communicate within the same Docker network.
- `--enable-host-networking` correctly configures host networking.
- No port conflicts when host networking is enabled.
- Generated `docker-compose.yaml` includes proper **network definitions** and **aliases**.
- Conversion works consistently across **Docker** and **Podman**.
- Documentation updated with networking configuration options and examples.

---

## Example

### Default bridge network
For a Helm chart with a main service and a logging sidecar communicating over `localhost:8080`:

```
services:
main-app:
image: my-app:latest
ports:
- "8080:8080"
networks:
- app-network
logging-sidecar:
image: logging-agent:latest
depends_on:
- main-app
networks:
- app-network

networks:
app-network:
driver: bridge
```

### With `--enable-host-networking`
```
services:
main-app:
image: my-app:latest
network_mode: host
logging-sidecar:
image: logging-agent:latest
network_mode: host
depends_on:
- main-app
```

No files, tests, or entry points are named. Start by locating the compose conversion and CLI argument-parsing entry points, then inspect existing handling of Helm-rendered manifests and networking. Done means the acceptance criteria pass for bridge and host networking, including aliases, port behavior, Docker and Podman compatibility, and updated documentation.

Written by the indexing model from the issue text.