No network when "udevadm settle" failed despite successful MAC spoofing

I've seen this happen in tails-debugging-info:

1. unblock network
2. udevadm trigger succeeds ⇒ triggers MAC spoofing, which succeeds
3. restarting systemd-udev-settle.service fails, maybe due to unrelated hardware problems (systemd-udevd[622]: hdaudioC1D0: Worker [644] processing SEQNUM=6198 is taking a long time) … so we abort and never start NetworkManager.service.
4. The users starts NetworkManager.service manually, after which the network works fine.

Since 18b2d121 we already avoid triggering events on graphics cards. I think we should exclude more subsystems, starting with those that we already know can cause trouble and is irrelevant to network devices:

• audio stuff
  • wb:c574af06b42dd0e78953defc3d009ead (timeout with hdaudioC1D0 and hdaudioC0D2)
• applesmc (wb:85adbcdbd84fbd6ee6d013d98e3686a1)
• more?

Benefit and cost

Most users affected by this problem won't get working network and thus won't manage to report an error, so likely the amount of reports we get is disproportionately small compared to the actual impact.

Excluding more device classes that are known to cause trouble should be cheap and safe.

Switching to an allowlist approach, where we trigger only relevant classes, is appealing but carries the risk of not triggering some necessary devices, which could lead to regressions on hardware that currently works fine. Evaluating and mitigating this risk is more expensive and not worth it.