[JENKINS-49567] Automatically support docker networks in pipelines with multiple containers

As is, it's not possible to create a Jenkinsfile with docker containers that need to communicate with each other (and not just a basic connection from container A to container B). For example, when running Behat tests for Drupal:

• The webapp container (with PHP etc) çontains Behat, which needs to be able to link to the Selenium container.
• The Selenium container needs to be able to link back to the webapp container to load pages.

This leads to a chicken-and-the-egg problem, since you can't know the ID of a container before it starts. I imagine there's a way to hack it with container names, but that seems collision prone.

Under other tools like Circle CI, a docker network is transparently created and all containers ports from their Dockerfiles are automatically exposed to each other. For example, even though there are two containers, from both perspectives all ports are available on localhost.

On top of this, the recommended --link parameter has been deprecated by docker, so moving to bridge networks will keep the plugin working with future Docker releases.

As is, it's not possible to create a Jenkinsfile with docker containers that need to communicate with each other (and not just a basic connection from container A to container B). For example, when running Behat tests for Drupal:

	
The webapp container (with PHP etc) çontains Behat, which needs to be able to link to the Selenium container.
	
The Selenium container needs to be able to link back to the webapp container to load pages.



This leads to a chicken-and-the-egg problem, since you can't know the ID of a container before it starts. I imagine there's a way to hack it with container names, but that seems collision prone.

Under other tools like Circle CI, a docker network is transparently created and all containers ports from their Dockerfiles are automatically exposed to each other. For example, even though there are two containers, from both perspectives all ports are available on localhost.

On top of this, the recommended --link parameter has been deprecated by docker, so moving to bridge networks will keep the plugin working with future Docker releases.

The issue names no files, tests, or entry points; begin by locating the docker-workflow-plugin code responsible for running multiple containers and its current --link handling. Review how pipeline container lifecycles are managed before considering the requested bridge-network behavior. Done means mutually reachable containers with their Dockerfile ports available as described, while supporting current Docker releases.