feat: logical timestamp & token bucket (Rebase of #145)

[Lethe10137]

Rebase #145 to #150.

[BobAnkh]

@Lethe10137 Please rebase the PR first. Ping me when it is ready for review

[Lethe10137]

By modifying the Delay cell, the recent commit (3fb0ac3) has (slightly) better tput than current main branch.

[BobAnkh]

@Lethe10137 cargo-audit fails, which means your new depencency have security vulnerability, please check which depencency use this.

[BobAnkh]

I haven't clearly checked the TBF's implementation, but let's first discuss the bandwidth cell. Let's decide how to define our logic and physical meaning of next_available together with the timestamp on the packet.

[BobAnkh]

I think we may need further discussion on how to set the current time for a packet within bandwidth-like cells. Given that we currently send packets at next_available, but they only arrive after next_available + transfer_time, should we update the packet's timestamp to next_available + transfer_time? In the current implementation (including previous versions), our packets are expected to arrive at the next cell at the time of next_available. I believe there may be design flaws in our previous approach. We may need some further discussion with @Lethe10137 and @Centaurus99

[BobAnkh]

Please review the bandwidth cell only, @Centaurus99

[Lethe10137]

@Lethe10137 cargo-audit fails, which means your new depencency have security vulnerability, please check which depencency use this.

mnl is a direct dependency of rattan, introduced when the nat feature was implemented.

[BobAnkh]

@Lethe10137 cargo-audit fails, which means your new depencency have security vulnerability, please check which depencency use this.

mnl is a direct dependency of rattan, introduced when the nat feature was implemented.

@Centaurus99 Please check it, as nat is implemented by you.

[Lethe10137]

The tput performance of current PR, 5d9b158, is slightly better than the main branch.

[BobAnkh]

@Lethe10137 Is everything ready for review again?