add support for `Complex` error types with `zerocopy`

[hawkw]

Presently, attempting to use encoding: Zerocopy with an IPC using the Complex error type produces an error, like this:

error: failed to run custom build command for `drv-cpu-seq-api v0.1.0 (/home/eliza/Code/oxide/hubris/drv/cpu-seq-api)`

Caused by:
  process didn't exit successfully: `/home/eliza/Code/oxide/hubris/target/release/build/drv-cpu-seq-api-43c66dba4c036f49/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /home/eliza/.cargo/git/checkouts/idolatry-1ebf1c2fd2f30300/6bc9555/src/client.rs:518:41:
  Complex error types not supported for Zerocopy encoding, sorry
  stack backtrace:

This is the case because previous versions of zerocopy did not support enums with data fields, and could only be used with C-like enums. However, zerocopy 0.8 adds support for deriving zerocopy's traits for enums with data fields. Now PR #57 has updated our zerocopy dependency to v0.8.x, we could presumably add support for the Complex error type on encoding: Zerocopy IPCs.

[hawkw]

I have a particular motivating use-case for this: oxidecomputer/management-gateway-service#271 (comment) proposes a solution for oxidecomputer/management-gateway-service#270 where the Sequencer::set_power_state IPC is modified to return the sequencer's current state as part of the IllegalTransition error variant so that the client can distinguish between cases where the requested transition is actually nonsensical and cases where the transition was invalid because the sequencer has already set the requested power state after the client last checked the power state (a TOCTOU issue where the "illegal transition" error actually indicates that the sequencer is in the desired state and everything is probably fine). Presently, the Sequencer::set_power_state (and set_power_state_with_reason) use encoding: Zerocopy with the CLike error, but adding the current state would, of course, necessitate changing this to the Complex error type.

I figured it might be worth just going ahead and making the codegen changes to support zerocopy for Complex errors, rather than changing the IPCs to use hubpack. But, I figured it was worth asking @cbiffle's opinion on this first, since I know you had been considering deprecating zerocopy in idol IPCs...

[cbiffle]

For the record:

• The reason I initially used zerocopy for IPCs was that it should, in theory, be awesome and low overhead and easy.
• The reason we moved away from it for many IPCs was that the space of Rust types it could reasonably describe and handle turned out to be somewhat limiting. (Only repr(C), limited enum support, third party crates rarely derive it, etc.) We have a lot of cases where APIs throw away error data (for instance) and collapse things down to an int, and it's almost always because they wanted to return the error through the zerocopy encoding instead of the more powerful serde Complex encoding. This makes me sad.
• If this gets fixed such that the user experience is better, I have fewer objections to continuing to support it.
• That being said, I have concerns about zerocopy and tooling support. I sort of liked the idea of moving in the direction of IDL files being entirely self-describing, so that tools could decode messages without having to load ELF binaries and think in DWARF. I started prototyping that over in exhubris. Zerocopy encoding in general is directly opposed to that goal: the structs get described in DWARF only, and their layout can change with the ABI (e.g. usize fields, c-like enums).

All that being said, I don't see a problem with improving our existing zerocopy support, even if we might remove it in the future, so, lemme take a look at what you've done!

[hawkw]

Okay, so it's still pretty limited in the data-bearing enum case: the data must always be the same width for the IntoBytes implementation to be padding-free. Hm.

[hawkw]

(I do have a working version of the codegen change though)