user container cannot receive uevents

**Describe the bug**
Programs in a standard Fedora toolbox don't receive uevents, i.e. udev events about hardware changes through the AF_NETLINK socket.

This is [supposed](https://dummdida.tumblr.com/post/121087781445/re-udev-events-in-a-container) [to work](https://stackoverflow.com/questions/49687378/how-to-get-hosts-udev-events-from-a-docker-container) with running the container in the host's network namespace (currently `--network=host`) and bind-mounting the host's dev. Issue #468 also sounds like this actually did work in the past.

**Steps how to reproduce the behaviour**
1. `toolbox create -r 37; toolbox enter -r 37`
2. `sudo dnf install -y /usr/bin/udevadm`
3. Start `udevadm monitor --udev` once in the toolbox, and once on the host
4. Trigger some `/dev` change. Plug in or remove a Yubikey, mouse, or keyboard; or do something like `sudo ip link add name e1 type veth` or `sudo modprobe scsi_debug`.

**Expected behaviour**
The host's udev monitor will see the event, like

UDEV [3612.352892] add /devices/pseudo_0/adapter0/host0/target0:0:0/0:0:0:0/block/sda (block)

for loading scsi_debug. Ideally, the toolbox should see this as well. This would make it possible to run things like gvfs, sway, calibre, or anything else that needs to react to hardware changes in toolbox.

**Actual behaviour**
udevadm in toobox does not see any event.

**Output of `toolbox --version` (v0.0.90+)**
toolbox version 0.0.99.3

**Output of `podman version`**
```
Client: Podman Engine
Version: 4.3.1
API Version: 4.3.1
Go Version: go1.19.2
Built: Fri Nov 11 16:01:27 2022
OS/Arch: linux/amd64
```

**Podman package info (`rpm -q podman`)**
podman-4.3.1-1.fc37.x86_64

**Info about your OS**
Fedora 37 OSTree (Silberblue-ish, but a [custom build](https://github.com/martinpitt/ostree-pitti-workstation)).

**Additional context**
I'm experimenting with running my whole desktop from toolbox/podman, see https://github.com/martinpitt/swaypod and https://github.com/martinpitt/swaypod/issues/1 .

Perhaps this is doomed to fail, but this issue is pretty much the only blocker, so I'd like to at least understand why :grin: Thanks!

Start by reproducing the issue with the listed toolbox create/enter commands and compare udevadm monitor output inside and outside the toolbox. Trace how toolbox configures the container's network namespace and device mounts. Done means the cause is documented and, if feasible, uevents triggered on the host are visible inside the toolbox without breaking existing isolation.

Written by the indexing model from the issue text.