Solidify recovery semantics

[samcday]

At a high level:

• Both gadget and host should be resilient to daemon crashes or USB link failures.
• If the link is interrupted for any reason, /dev/ublkbN should hang around (UBLK_F_USER_RECOVERY ensures this)
• Once both sides are talking again, any pending I/O on the ublk side should be processed as normal.

End result: you can dd if=/dev/ublkbN, unplug the cable and see dd halt, plug back in and see I/O operations continue on as though nothing happened.

Much of this has already been implemented vibed out already:

• The host initiates periodic CONFIG_STATUS ep0 IN requests to make sure the gadget side is alive.
• The gadget replies with its session ID (generated randomly on non-recovery startup).
• This allows the host to react if session_id changes (because the gadget went away and came back in a different state than expected).
• Currently the host handles this by simply exiting out. Ideally it would just throw away most of its runtime state and start over (but maybe crash-driven design is better here anyway).
• The gadget serializes the CONFIG_EXPORTS list it got, along with the session_id it generated, into a state file when it boots up.
• If that file already exists on startup, the gadget will enter a recovery path (pick the orphaned ublk devices back up)

The UBLK_F_USER_RECOVERY semantics are kinda scary, though - it seems to be very easy to wedge ublk-drv in a way that leaves devices in a very broken state.

There's also still soundness issues in how the gadget/host handle the various failure modes, robustly.

We'll consider this work complete when the various failure modes (host crashing and coming back, gadget crashing and coming back, USB link severed, etc) have been well tested. Ideally we can wire up some integration tests with dummy_hcd that kill -9 the daemons at various stages and confirms the e2e behaviour on the /dev/ublkbN device.

[samcday]

Made a bunch of progress here.

The export handling semantics are formalized in the new ExportController reconciler-thingie. There's still some sharp edges, but everything is mostly in place to ensure that the gadget daemon owns the lifecycle of its ublk devices robustly, even across crashes.

For the live-boot rootfs use case, we want UBLK_F_USER_RECOVERY | UBLK_F_USER_RECOVERY_REISSUE on the ublk targets. This ensures that the filesystem layers just see a very slow to complete i/o request if the USB link is severed or a daemon crashes.

We'll probably need to retrofit BlockSource a bit to handle this better. I think maybe the write path should be a separate trait. If a particular BlockSource provides it, we do not set UBLK_F_USER_RECOVERY_REISSUE (or maybe the new write-focused trait could indicate if that's permissible).

Currently vibing out a bunch more ceremony to encode the icky bits of properly tracking and retrying in-flight i/o (stuff we caught off the ublk target's uring but have not yet sent a Request and/or Response for, yet). So the high-level vision in the description is inching closer to fruition.