Remove incorrect difference between user-defined and default bridge (#10320)

* Remove incorrect difference between user-defined and default bridge

This PR removes the first bullet point from the list differences between user-defined bridge networks and the default bridge network:

[User-defined bridges provide better isolation and interoperability between containerized applications](https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge).

The default bridge network, similar to user-defined bridges, opens all ports to other containers and allows for inter-container communication by default. This is elaborated and demonstrated in #8973. Other relevant issue: #8437.

* Remove mention of previous bullet point

* Added isolation advantage of user-defined over default network

network/bridge.md

@@ -34,25 +34,6 @@ network.**
 
 ## Differences between user-defined bridges and the default bridge
 
-- **User-defined bridges provide better isolation and interoperability between containerized applications**.
-
-  Containers connected to the same user-defined bridge network automatically
-  expose **all ports** to each other, and **no ports** to the outside world. This allows
-  containerized applications to communicate with each other easily, without
-  accidentally opening access to the outside world.
-
-  Imagine an application with a web front-end and a database back-end. The
-  outside world needs access to the web front-end (perhaps on port 80), but only
-  the back-end itself needs access to the database host and port. Using a
-  user-defined bridge, only the web port needs to be opened, and the database
-  application doesn't need any ports open, since the web front-end can reach it
-  over the user-defined bridge.
-
-  If you run the same application stack on the default bridge network, you need
-  to open both the web port and the database port, using the `-p` or `--publish`
-  flag for each. This means the Docker host needs to block access to the
-  database port by other means.
-
 - **User-defined bridges provide automatic DNS resolution between containers**.
 
   Containers on the default bridge network can only access each other by IP
@@ -60,10 +41,9 @@ network.**
   considered legacy. On a user-defined bridge network, containers can resolve
   each other by name or alias.
 
-  Imagine the same application as in the previous point, with a web front-end
+  Imagine an application with a web front-end and a database back-end. If you call
-  and a database back-end. If you call your containers `web` and `db`, the web
+  your containers `web` and `db`, the web container can connect to the db container
-  container can connect to the db container at `db`, no matter which Docker host
+  at `db`, no matter which Docker host the application stack is running on.
-  the application stack is running on.
 
   If you run the same application stack on the default bridge network, you need
   to manually create links between the containers (using the legacy `--link`
@@ -72,6 +52,12 @@ network.**
   Alternatively, you can manipulate the `/etc/hosts` files within the containers,
   but this creates problems that are difficult to debug.
 
+- **User-defined bridges provide better isolation**.
+
+  All containers without a `--network` specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate.
+
+  Using a user-defined network provides a scoped network in which only containers attached to that network are able to communicate.
+
 - **Containers can be attached and detached from user-defined networks on the fly**.
 
   During a container's lifetime, you can connect or disconnect it from