Enums in FFI types are unsafe

[Stebalien]

It looks like we're using enums in FFI types in several places, but this is inherently unsafe as we can end up creating enums with arbitrary values and the rust type system will assume that this can't happen.

This can cause problems like:

1. Code checking said enum value may be optimized away.
2. If the enum has no zero variant but a zero is passed, rust may interpret Option<Enum> as None.
3. Really, whatever the rust compiler wants to do.

[dignifiedquire]

Asfaict all enums that are used are using repr(C) which should make them FFI safe, so I don't think these concerns apply.

[Stebalien]

It's unsafe because we call into the FFI from go without checking whether the enum variant is valid. That means we could end up constructing an "impossible" enum variant (e.g., 9999, when the only valid enum variants are 0-5). Given that the rust compiler assumes that enum variants are statically "valid" without checking, this could, e.g., cause a match statement (if implemented as a jump table) to jump to some random offset in memory.

[Stebalien]

Fixed.