vsock: make the descriptor chain parsing more generic

[lauralt]

The device implementations that we have are Linux specific in terms of how their messages (packets for vsock, requests for block) are split between descriptors. For example, in the case of the vsock device the packet contents had the following distribution: the header on the first descriptor buffer, and the data on an optional second descriptor buffer. This was valid until Linux 6.2; starting with this version you can have both the header and data in a single descriptor (quick fix for this here). That is because the spec is not enforcing a specific layout for the messages, the only thing the descriptor chain layout needs to satisfy is: The driver MUST place any device-writable descriptor elements after any device-readable descriptor elements..

We should fix at least the vsock packet implementation (since the crate is already published and consumed) so that it can fit any valid message layout, i.e. header on any number of descriptors and same for the data buffer (which in terms of implementation translates to header and data having a Vec<VolatileSlice> as type instead of one VolatileSlice). A discussion about this was already started here. I'm expecting the VsockPacket abstraction can't be nicely fixed without also introducing abstractions for parsing the descriptor chains, such as the Reader and Writer proposed here, other implementation for them can be found also here. One suggestion that I have is to resume (or at least look over) the PR linked above. By adding such abstractions, any other device implementation can be then easily switched to use them.

[stefano-garzarella]

I think we can use https://github.com/rust-vmm/vm-virtio/pull/278 to fix this issue. I'll try in the next weeks, but any help is more than welcome :-)