virtio_random: defer first enqueue until after DRIVER_OK

[kevans]

Summary

According to the virtio spec:

The driver MUST NOT send any buffer available notifications to the
device before setting DRIVER_OK.

DRIVER_OK isn't set until after attach completes, so defer the first
enqueue. We haven't found any problems as a result of this to the best
of my knowledge: q35 and other devices that we *have* been used with
will apparently check when we go DRIVER_OK.

Tested with q35 virtio-random, which still works.

Reported by: llm-postcr
Fixes: f1c5a2e3a62505 ("virtio_random: Pipeline fetching the data")

[kevans]

It kind of looks like Firecracker is probably impacted by this; @cperciva do you happen to have a VM around that you can check virtio-random on? Something like this would confirm whether we're actually getting anything from it:

dtrace -n 'fbt::vtrnd_read:return { @[arg1 ? "bytes" : "empty"] = count(); }'

[cperciva]

In D61228#1403840, @kevans wrote:

It kind of looks like Firecracker is probably impacted by this; @cperciva do you happen to have a VM around that you can check virtio-random on? Something like this would confirm whether we're actually getting anything from it:

dtrace -n 'fbt::vtrnd_read:return { @[arg1 ? "bytes" : "empty"] = count(); }'

Sorry, I haven't had a chance to play with Firecracker for quite a while. When I was using it we just got entropy from the CPU.