• backport Recover from default bridge init failure #49292
• fixes Error initializing Docker network controller: Conflict with existing bridge network docker0 #49291
• ⚠️ also cherry-picks the first commit (24f53eb) from Only set ip6tables filter-FORWARD DROP if necessary #48594, as tests were moved in main; cherry-pick had no conflicts in files, but the rename was ambiguous;

git cherry-pick -s -S -x 22c02219de46b4565388491b18cbfcf61ce5ad3f
CONFLICT (directory rename split): Unclear where to rename integration/network/bridge to; it was renamed to multiple other directories, with no destination getting a majority of the files.
Auto-merging libnetwork/drivers/bridge/bridge_linux.go
Auto-merging testutil/daemon/daemon.go
error: could not apply 22c02219de... Bridge: on network delete, make sure it's deleted from store

If a bridge network can't be restored from the store on startup, then it's deleted, the daemon and bridge driver get out of step. If that happens to the default bridge, the daemon can't recover, it won't start again.

See the issue for more detailed description/analysis.

The ipvlan/macvlan/overlay network drivers don't seem to be affected by an equivalent issue.

This is a very long standing issue, but perhaps provoked by the checks on kernel module loading added in 27.x. (The version label on the PR is arbitrary, just something-old.)

- How I did it

When deleting a network the bridge driver doesn't know about, make sure it's not still lurking in the data store.

- How to verify it

New tests.

- Description for the changelog

- Fixed an issue that could persistently prevent daemon startup after failure to initialize the default bridge.