Create v6::OROCodes (#1)

[Mattbazooka]

I have added a type for ORO codes because not all Option Codes are valid here.
Are there any changes that could be made to make this better?

[leshow]

Hello! Thanks for the PR. I ran the pipeline and got some errors. I hadn't considered splitting the option type before, but it makes sense. Elsewhere we have gone for a more "rust-y" naming style, how do you feel about renaming variants like VENDOR_OPTS to PascalCase like VendorOpts?

And then, for the OptionCodes type, I'm assuming we want that to be a superset of all options?

[Mattbazooka]

I do think having OptionCodes being a superset of all options would be a good idea.

I'm also thinking of splitting DhcpOption and creating some types for holding the IA_NA/IA_TA, and IA_PA options as this would make the library easier to use since they only accept a couple of options (rfc8415#appendix-C).

[Mattbazooka]

Something along the lines of this https://github.com/Mattbazooka/dhcproto/tree/v6_rewrite

[leshow]

I apologize for not looking at this sooner, thanks so much for doing all of this!

[leshow]

Should we just derive Ord & PartialOrd?

[leshow]

we can remove this and just add Ord, PartialOrd to the derive I think

[leshow]

If we can fix the pipeline then LGTM

[Mattbazooka]

This is all I've got at the moment, I might not be able to work on this for a while as the communication lines got fried about a week ago and I'm still currently without phone or internet.

I don't know if we should, or should not derive Ord, I'll leave it up to whoever wants to test to see which differences there are.

If you would like me to do anything I should be available again soon.

[leshow]

Woah! I didn't look through the rewrite branch in your comment, I was just commenting on what was in the actual PR last time. I probably would have preferred to land some of these changes in smaller bits because it is quite a lot to review.

However, you've done all this work and I don't want to throw it out so I'll likely add a few commits on top if you don't mind. Thanks for all your effort.

[leshow]

OK, I took a little closer look through this. I think I would prefer to land the option codes changes and oro_codes types first. I'll comment on the ticket which parts I'm talking about. I'm not as convinced about the change to the message decoding where we move the msg type into an enum, and the same with the options. If it really improves usability for the API, then maybe, but I'd like to see some examples of it first so we can discuss.

If you want to submit a new PR with the option codes stuff, I will happily land that, and we can use this PR to keep talking about the API changes.