This function doesn't init the bridge driver - it's already
initialized! - so no need to call it this way.

Signed-off-by: Albin Kerouanton <[email protected]>

Commit 268d418 added persistence to the bridge driver, and added logic
to not delete the bridge interface if it's used by the default bridge
network when the later is deleted (as part of the networking
initialization steps).

Later on, commit 6bd1539 refined this logic to not delete the bridge
interface if it's user-managed. But it didn't touch the original
condition (ie. do not delete the bridge interface if it's used by the
default network).

And then, commit 173b3c3 added support for the `default-address-pools`
parameter. It also added some code to delete the bridge interface used
by the default network, but in the daemon instead of leveraging the
usual delete flow in the bridge driver. It also skips the deletion if
no `default-address-pools` are defined.

This leads to a corner case where the bridge interface isn't recreated
when `default-address-pools` is unset.

Tidy this up by letting the bridge driver delete the bridge interface
even when it's used by the default network. There are two exceptions
where the underlying interface shall not be deleted:

1. When the interface is user-managed. User is responsible for creating
  and deleting it.
2. When live-restore is enabled and there are containers running.

Note that the 2nd exception could be refined to only apply when there
are active sandboxes attached to that network, but this is out of scope.

Signed-off-by: Albin Kerouanton <[email protected]>