Dockerfile: update to Debian "bookworm", and update frozen images to debian:bookworm-slim
- [x] depends on https://github.com/moby/moby/pull/46852
- [x] depends on https://github.com/moby/moby/pull/46854
- [x] depends on https://github.com/moby/moby/pull/46859


### quota: increase sparse test-image to 300MB
Starting with [6e0ed3d19c54603f0f7d628ea04b550151d8a262], the minimum
allowed size is now 300MB. Given that this is a sparse image, and
the size of the image is irrelevant to the test (we check for
limits defined through project-quotas, not the size of the
device itself), we can raise the size of this image.

[6e0ed3d19c54603f0f7d628ea04b550151d8a262]: https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=6e0ed3d19c54603f0f7d628ea04b550151d8a262


### Dockerfile: update to Debian "bookworm" (current stable)

Debian Woodworm ships with a newer version of iptables, which caused two
tests to fail:

    === FAIL: amd64.integration-cli TestDockerDaemonSuite/TestDaemonICCLinkExpose (1.18s)
    docker_cli_daemon_test.go:841: assertion failed: false (matched bool) != true (true bool): iptables output should have contained "DROP.*all.*ext-bridge6.*ext-bridge6", but was "Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)\n pkts bytes target     prot opt in     out     source               destination         \n    0     0 DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0           \n    0     0 DOCKER-ISOLATION-STAGE-1  0    --  *      *       0.0.0.0/0            0.0.0.0/0           \n    0     0 ACCEPT     0    --  *      ext-bridge6  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED\n    0     0 DOCKER     0    --  *      ext-bridge6  0.0.0.0/0            0.0.0.0/0           \n    0     0 ACCEPT     0    --  ext-bridge6 !ext-bridge6  0.0.0.0/0            0.0.0.0/0           \n    0     0 DROP       0    --  ext-bridge6 ext-bridge6  0.0.0.0/0            0.0.0.0/0           \n"
    --- FAIL: TestDockerDaemonSuite/TestDaemonICCLinkExpose (1.18s)

    === FAIL: amd64.integration-cli TestDockerDaemonSuite/TestDaemonICCPing (1.19s)
    docker_cli_daemon_test.go:803: assertion failed: false (matched bool) != true (true bool): iptables output should have contained "DROP.*all.*ext-bridge5.*ext-bridge5", but was "Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)\n pkts bytes target     prot opt in     out     source               destination         \n    0     0 DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0           \n    0     0 DOCKER-ISOLATION-STAGE-1  0    --  *      *       0.0.0.0/0            0.0.0.0/0           \n    0     0 ACCEPT     0    --  *      ext-bridge5  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED\n    0     0 DOCKER     0    --  *      ext-bridge5  0.0.0.0/0            0.0.0.0/0           \n    0     0 ACCEPT     0    --  ext-bridge5 !ext-bridge5  0.0.0.0/0            0.0.0.0/0           \n    0     0 DROP       0    --  ext-bridge5 ext-bridge5  0.0.0.0/0            0.0.0.0/0           \n"
    --- FAIL: TestDockerDaemonSuite/TestDaemonICCPing (1.19s)

Both the `TestDaemonICCPing`, and `TestDaemonICCLinkExpose` test were introduced
in dd0666e64f17329355c77aae1a2ac0fe2fe43402. These tests called `iptables` with
the `-n` option. This option prevents it from doing a reverse-DNS lookup as an
optimization.

However, the `-n` option did not have an effect to the `prot` column before
commit [da8ecc62dd765b15df84c3aa6b83dcb7a81d4ffa] (iptables < v1.8.9 or v1.8.8).
Newer versions, such as the iptables version shipping with Debian Woodworm do,
so we need to update the expected output for this version.

With this change;

    make DOCKER_GRAPHDRIVER=vfs TEST_FILTER=TestDaemonICC  TEST_IGNORE_CGROUP_CHECK=1  test-integration
    ...
    --- PASS: TestDockerDaemonSuite (139.11s)
        --- PASS: TestDockerDaemonSuite/TestDaemonICCLinkExpose (54.62s)
        --- PASS: TestDockerDaemonSuite/TestDaemonICCPing (84.48s)

[da8ecc62dd765b15df84c3aa6b83dcb7a81d4ffa]: https://git.netfilter.org/iptables/commit/?id=da8ecc62dd765b15df84c3aa6b83dcb7a81d4ffa


### Dockerfile: remove uses of DEBIAN_FRONTEND

We used DEBIAN_FRONTEND in some places to prevent installation of packages
from being blocked. However, debian bookworm now [includes a fix][1] for
situations like this (it was specifically reported for Docker situations <3),
so we can get rid of these.

Thanks to Tianon for noticing this, and for linking to the Debian ticket!

[1]: https://bugs.debian.org/929417


### frozen images: update to debian:bookworm-slim

<!--
Please make sure you've read and understood our contributing guidelines;
https://github.com/moby/moby/blob/master/CONTRIBUTING.md

** Make sure all your commits include a signature generated with `git commit -s` **

For additional information on our contributing process, read our contributing
guide https://docs.docker.com/opensource/code/

If this is a bug fix, make sure your description includes "fixes #xxxx", or
"closes #xxxx"

Please provide the following information:
-->

**- What I did**

**- How I did it**

**- How to verify it**

**- Description for the changelog**
<!--
Write a short (one line) summary that describes the changes in this
pull request for inclusion in the changelog:
-->


**- A picture of a cute animal (not mandatory but encouraged)**


cli/winresources/README.md
## Generate `event_messages.bin`

```console
$ docker run --rm -it -v "$(pwd):/winresources" debian:bullseye bash
root@9ad2260f6ebc:/# apt-get update -y && apt-get install -y binutils-mingw-w64-x86-64
root@9ad2260f6ebc:/# x86_64-w64-mingw32-windmc -v /winresources/event_messages.mc
root@9ad2260f6ebc:/# mv MSG00001.bin /winresources/event_messages.bin
```

## Generate `event_messages.bin`

```console
$ docker run --rm -it -v "$(pwd):/winresources" debian:bookworm-slim bash
root@9ad2260f6ebc:/# apt-get update -y && apt-get install -y binutils-mingw-w64-x86-64
root@9ad2260f6ebc:/# x86_64-w64-mingw32-windmc -v /winresources/event_messages.mc
root@9ad2260f6ebc:/# mv MSG00001.bin /winresources/event_messages.bin
```

Should we update this one to `-slim` too while we're at it, for consistency? (I think we're now using `-slim` pretty much everywhere else :sweat_smile:)