Adding a per-packet delay trace

[maxime-bruno]

Adding per-packet delay traces

Description

Following this discussion on rattan, I'm proposing the modification needed to netem-trace.

This pull request introduces a new type of trace, specifically a per-packet delay.
This trait allows the generation of delay on a packet basis, instead of a time spawn.
This is intended to be used to allow delaying packets in a way that may introduce reordering of packets.

Introduced types and traits:

• DelayPerPacketTrace: the main trait
• StaticDelayPerPacket: a per-packet delay trace that returns a constant delay for a specific number of packet
• NormalizedDelayPerPacket: a per-packet delay trace that returns a delay produced by a seedable normal law for a specific number of packet
• RepeatedDelayPerPacketPattern: a per-packet delay trace which is a repetition of per-packet delay traces
• The configs for the traces
• DelayPerPacketTraceConfig: a trait to convert a config in the trace
• Forever: a trait to convert a trace in an endless repetition of itself

(I also corrected some typos)

How Has This Been Tested

I tested using the unit test and doc test included, I'm open to adding additional.

Types of changes

New feature (non-breaking change which adds functionality)

Checklist

• Code follows the code style of this project.
• Changes follow the CONTRIBUTING guidelines.
• Update necessary documentation accordingly.
• Lint and tests pass locally with the changes.
• Check issues and pull requests first. You don't want to duplicate effort.

[maxime-bruno]

I added the log-normal per-packet delay trace.

I did not implement the truncated correct version as I do not master the math to do it.

[BobAnkh]

LGTM. The only thing to change is: could you please fix the clippy warnings? I will squash-merge the PR once your fix is pushed.

[BobAnkh]

Really thanks for your correction on typos across the crate and the implementations of the trace type and traits.

I did not implement the truncated correct version as I do not master the math to do it.

You don't have to implement the truncated correct version, or just leave it as it is.

Once the fix for clippy warnings is pushed, I will merge and publish a new version of this crate to use in rattan.

[maxime-bruno]

I'll take care of this on Monday
And edit the change log

[BobAnkh]

Thank you. But can you revert your modification on CHANGELOG.md? 😂 I misunderstood you. You don't need to modify the changelog; it will be generated automatically on release.

[maxime-bruno]

Will do so, no problems

I was thinking that using StdRng which is not portable, is a good idea by default, but it would be better to allow the user to choose the random generator used.
What would be your takes on a build function with this signature: pub fn build<Rng: SeedableRng + RngCore>(&self) -> NormalizedDelayPerPacketTrace<Rng>
And pub struct NormalizedDelayPerPacketTrace<Rng = StdRng> where Rng: RngCore ?
Or maybe another method like build_with_rng and build is just a call to build_with_rng::<StdRange>

[BobAnkh]

Regarding Rng, I have also considered this issue before. Although StdRng is sufficient for me, I would be happy to see more possibilities supported on Rng if you wish to contribute. I'm fine with such signatures, as long as the tests and functioning of netem-trace and rattan still work correctly. Additionally, I believe that further unit tests are necessary to verify the correctness with other RNG generators (e.g., OsRng or others) and serve as an example of usage. Feel free to send me a new PR on this.

However, I just noticed that here the build methods for some types use &self instead of self. I think it would be better to unify with the existing interface design and use self. What do you think?

[maxime-bruno]

Following Rust's best practice, I used &self whenever possible.
Only RepeatedDelayPerPacket needs self as a Vec does not implement Copy.
Technically, build_truncated should take a &mut self but I thought that taking mut self was more idiomatic.

But I agree with the fact that the non-homogeneity may be an issue

[BobAnkh]

At that time, I considered homogeneity, so I unified the signatures of all build functions to self, given the usage scenarios of the config. This was also done considering that some build methods might change the state of some variables in the config, so it's not possible to repeatedly construct the same trace.

[BobAnkh]

Really thanks for your contributions!