feat: add types and de/encoding for SCMP messages

[mlegner]

Contributes to #54

Closes #112

[github-actions]

Package	Line Rate	Health
crates/scion/src	79%	✔
crates/scion-proto/src/scmp	78%	✔
crates/scion-proto/src	80%	✔
crates/scion-proto/src/path	82%	✔
crates/scion-proto/src/address	70%	➖
crates/scion/src/pan	49%	❌
crates/scion-proto/src/path/metadata	100%	✔
crates/scion/src/daemon	95%	✔
crates/scion-proto/src/packet/headers	86%	✔
crates/scion-proto/src/path/standard	90%	✔
crates/scion-proto/src/reliable	95%	✔
crates/scion-proto/src/packet	83%	✔
Summary	80% (1542 / 1927)	✔

[jpcsmith]

Hey Markus, looking good.

One thing that wasn't clear is why the Other* enum variants start from 0.

[mlegner]

I've created a separate issue for the tests (#112) so that we can get this merged more quickly and continue with actually handling SCMP messages.

Added some basic conversion tests.

[jpcsmith]

Hey Markus,

Thanks for all of your work on this. I made an initial pass, but still need to go through the details of each of the messages. In the mean time, I figured I could already let you have my thoughts so far. I feel that most of what you have here is good, my main issue being with your usage of traits (here comes object-safety).

First, since traits need to be imported to use the associated methods, having the methods spread over too many traits can be uncomfortable to use. Currently there are traits for the basic methods, one with the checksum methods, and ones for information and error messages, which do not follow the object relationship:

1. ScmpMessageBasicData -> Sized
2. ScmpMessageEncodeDecode -> ScmpMessageBasicData
3. ScmpErrorMessage
4. ScmpInformationalMessage

To use most functionality, one would need to import at least n1, n3, or n1 and n4, and additionally n2 if one needs information about the checksum. Perhaps the following structure would be more usable:

1. ScmpMessageBase
2. ScmpMessageEncodeDecode -> ScmpMessageBase + Sized
3. ScmpErrorMessage -> ScmpMessageBase
4. ScmpInformationalMessage -> ScmpMessageBase

This would allow importing only n3 or n4 depending on the use-case. n2 could also be rolled into n1, since all ScmpMessages would implement it. But I imagine that logic may be used more rarely, so perhaps that's not necessary.

Second, it would be nice if n1, n3, and n4 could all be object safe. This would allow creating a Box<dyn ScmpMessageBase> where one does not care about the type of message being passed around. The current trait forces ScmpMessageBasicData to only be used with static dispatch. Doing this would require removing the associated const MESSAGE_TYPE, which could be placed on the the actual struct and then used in the implementation of the trait.

Rolling n2 into n1, would complicate the above, since that uses generic functions and returns Self in one of its methods.

Finally, ScmpMessageRaw, despite technically being a ScmpMessage, does not implement any of the traits. I would have expected it to implement n1 and n2.

[mlegner]

@jpcsmith I've reorganized the traits in 0c2bc28. I made ScmpMessageBase public and split off a new public trait ScmpMessageChecksum, both of which are now also implemented by ScmpMessageRaw. I kept the ScmpMessageEncodeDecode private, as this mainly consists of helper functions.

Let me know what you think.

[jpcsmith]

Hey Markus, thanks for the changes. Looks good to go.