Add configuration knob for unpacker network

[31KM]

Is your feature request related to a problem? Please describe

See the discussion for context: https://github.com/orgs/portainer/discussions/10494

In short: the temporary unpacker container used by the Local filesystem path feature only joins the default bridge network. However, depending on the setup this will lead to issues:

• The portainer agent is used to allow host management
• Service containers are segmented in a user network (e.g. apps)
• One such service container might be a Gitea instance that hosts the docker compose stacks
• A new stack in the agent environment is created that uses a git repository as source
• The repo URL used would be http://[GITEA_APPS_IP]:[PORT]/MyUser/docker-stacks.git
• A local is configured and the agent container also has this mounted
• The deployment fails as the unpacker cannot reach Gitea, error message I/O timeout
• While the unpacker creates the folder in the specified local path it remains empty

The temporary unpacker container only joins the default bridge network.

Note, that The portainer main container and the agent container also need to join the apps network as otherwise the validation in the repo URL input field fails with context deadline exceeded.

Describe the solution you'd like

It should be possible to specify additional networks that the temporary unpacker container can join instead of only the default bridge network. That allows a lot more flexibility.

Describe alternatives you've considered

The only workaround I managed to find is that the portainer main container, the agent container and the Gitea container join the default bridge network. Then, instead of using the apps network IP for the repo URL one can use the bridge IP which makes the deployment work.

However, this has the following downsides:

1. Not flexible
2. It is not possible (AFAIK) to make a container join a custom network (like apps) in addition to the default bridge network from a compose.yml. So manual handling or insane scripting is required to make this work, which is error prone.

Additional context

No response

[31KM]

I also raised an issue portainer/portainer-docs#293 with portainer-docs to include this caveat while this feature request waits for a response.