Add Gateway Opcode enum

[bitfl0wer]

Introduces and publicly exports an enum Opcode which represents all currently known Opcodes that can be sent to/received from Spacebar Gateway Protocol compatible services.

[kozabrada123]

Generally I'm not opposed to this, but #527 (comment) kind of applies here as well. #[non_exhaustive] is definitely a solution, we could possibly even add the other two.

Though I think in our client implementation we shouldn't use these kinds of enums, since in the case we receive a variant we haven't added yet we'd just get a deserialization error, so I prefer a u8 and constants

[bitfl0wer]

Generally I'm not opposed to this, but #527 (comment) kind of applies here as well. #[non_exhaustive] is definitely a solution, we could possibly even add the other two.

non-exhaustive is a good solution, I think. I am also not sure about the comment on #527. We are implementing API v9 for now, which is pretty much fixed at this point.

Though I think in our client implementation we shouldn't use these kinds of enums, since in the case we receive a variant we haven't added yet we'd just get a deserialization error, so I prefer a u8 and constants

You'd have the same problem when using u8/consts, no? As in, if you encounter an undefined opcode, that will be an error which has to be handled somehow.

[kozabrada123]

Generally I'm not opposed to this, but #527 (comment) kind of applies here as well. #[non_exhaustive] is definitely a solution, we could possibly even add the other two.

non-exhaustive is a good solution, I think. I am also not sure about the comment on #527. We are implementing API v9 for now, which is pretty much fixed at this point.

Though I think in our client implementation we shouldn't use these kinds of enums, since in the case we receive a variant we haven't added yet we'd just get a deserialization error, so I prefer a u8 and constants

You'd have the same problem when using u8/consts, no? As in, if you encounter an undefined opcode, that will be an error which has to be handled somehow.

Yes, but I prefer handling it as: "Unexpected opcode, please open an issue" instead of "Failed to deserialize gateway message". That's how we handle it now.

We are implementing API v9 for now, which is pretty much fixed at this point.

Sadly I don't think that's the case, especially for the user api 🥴

[bitfl0wer]

To add some context for this PR:
I need to match GatewayEvents for the Gateway impl in symfonia. This requires me to match the u8 opcode to an Event type. To avoid mismatches, I thought it'd be a good idea to have chorus act as a single source of truth for this. The enum is not entirely necessary - pub exported consts would also work, but they'd arguably amount to the same solution in the end.

[bitfl0wer]

Yes, but I prefer handling it as: "Unexpected opcode, please open an issue" instead of "Failed to deserialize gateway message". That's how we handle it now.

Is this not something that is up to us? When handling incoming gateway messages, if the opcode does not match anything in Opcode, we can handle it as you described, no?

[kozabrada123]

Yes, but I prefer handling it as: "Unexpected opcode, please open an issue" instead of "Failed to deserialize gateway message". That's how we handle it now.

Is this not something that is up to us? When handling incoming gateway messages, if the opcode does not match anything in Opcode, we can handle it as you described, no?

We could do that, sure. But then the field that serde deserializes will still have to be a u8, which is kind of ugly. I suppose what we'd do then is manually try do fit it into the enum and display the same message as we do now

[bitfl0wer]

And what about the as-is solution, where the consts we declare simply refer to the Opcode type as u8? This way, we have both the publicly exported Opcode type and no further code-changes are needed, if I am not mistaken.

[kozabrada123]

Sure, that's the easiest solution. Since the constants now just relate to the enum as u8, we could also remove them, but it honestly doesn't matter

[bitfl0wer]

I can do that! Thank you for your review, your opinion is, as always, much appreciated :))