Fix incorrect deduplication of flood packets

[neilalexander]

We were, in many cases, adding packets into the deduplication table before checking whether the packet was even eligible for forwarding. This could mean that we drop packets that should have been allowed.

For example, the flood limit is set to 10. The first copy of a packet arrives with a path length of 12. The second copy of the same packet arrives via a different route with a path length of 8. The first packet is not forwarded because it exceeds the path length but it is still entered into the deduplication table, which results in the second packet also being dropped when it should have been forwarded.

[neilalexander]

I've changed the approach here somewhat so that the tables track dispatches and forwards separately, otherwise it's extremely hard to solve this problem properly. That should stop us from suppressing dispatches for packets that aren't eligible for forwarding, and still allow us to defer setting the forwarded bit until after the packet forwarding checks have been done.

[ripplebiz]

I think separating hasSeen() into two methods like this: #2880
Could be simpler?

[neilalexander]

That maybe simplifies things, but I don't think it fixes the problem. The issue is that a repeater must only mark the packet as a duplicate for forwarding if we actually intend to forward it.

I've rebased and tweaked things, curious on your thoughts.

[ckoehler]

Not sure I'm much help here, the behavior isn't super clear to me. I did write a test that I think shows the behavior you want, which currently fails. Once that passes, the behavior would be correct.

ckoehler@cf40b76

Maybe it'd be a starting point to add some tests to your PR/verify it's working as intended?