Churn test

[the-headless-ghost]

Description

Closes #5291

Checklist

Quality

• Commit sequence makes sense and have useful messages, see ref.
• New tests are added and existing tests are updated.
• Self-reviewed the PR.

Maintenance

• Linked an issue or added the PR to the current sprint of ouroboros-network project.
• Added labels.
• Updated changelog files.
• The documentation has been properly updated, see ref.

[crocodile-dentist]

I wonder if we can make it more uniform and like some other tests because I don't think we need an eventMap or targetsChangeEventMap and do all this extra processing which makes it perhaps more difficult to follow that it is. So the events binding should have the type [Events (WithName NtNAddr DiffusionTestTrace)] (see eg. prop_diffusion_cm_valid_transitions) and we should have a value which is a Signal TraceTargetsChanged where it is just the target change for the node you happen to be checking. Then the test is just conjoin (\ev -> ... signalProperty ...) events. Take a look at how this is done in prop_only_bootstrap_peers_in_fallback_state and maybe adapt it here slightly.

[coot]

Very nice! LGTM

[coot]

@crocodile-dentist is right, we don't need to build the maps. It's much better to analyse the trace as a stream if possible.

[crocodile-dentist]

I would also add a check that we decrease established peers by at least as how many active peers we have decreased, and analogously for big ledger peers.

[the-headless-ghost]

Do you mean this: establisheds - establisheds' >= actives - actives'?

[crocodile-dentist]

Yes, the logic we are trying to test is this in Churn:

    decreaseWithMin :: Int -> Int -> Int
    decreaseWithMin u v =  max 0 $ v - max u (max 1 (v `div` 5))

So we want to take the difference between established and active, and lower it by 20% or 1, whichever is greater, but also at least as many as active peers we have churned.
@karknu @coot should this be min v $ max u (max 1 (v div 5)) - this should catch some corner cases where we churn a few active peers, but the node is configured to use very few established peers in excess of the active target. This change will churn out all excess established peers even if the number of them is less than how many active peers we have churned. Or should this be an invariant violation that we check in the sane targets function - ie. it should be a misconfiguration where the number of excess established peers is less than the fraction of active peers churned at each cycle?

[coot]

I guess you mean decreaseWithMin u v = max 0 $ v - min v $ max u (max 1 (v div 5)), isn't it?

[crocodile-dentist]

It's starting to get unwieldy, but what about v - min v (max u (max 1 (v div 5)))?