reduce the frequency of client and server diverging before they reach startTick

[fraser-iohk]

This PR changes the generator for ChainSyncClientSetup such that startTick is now heavily weighted to pick a lower value (closer to 1) rather than a linear range between 1 and maxStartTick. This causes fewer randomly-generated ChainSyncClientSetups to produce test runs in which no headers are sent due to immediate divergence.

Before:

ouroboros-consensus
  ChainSyncClient
    chainSync: OK (5.69s)                                                              
      +++ OK, passed 10000 tests:
      67.35% ForkTooDeep
      27.89% NoMoreIntersection
       0.25% RolledBackPastIntersection
      
      TickArrivalTimeStats (10000 in total):
      67.40% OnlyNotEarly_SomeEarly Zero Zero
      10.76% OnlyNotEarly_SomeEarly Zero Many
       6.72% OnlyNotEarly_SomeEarly One Many
       5.95% OnlyNotEarly_SomeEarly One One
       3.75% OnlyNotEarly_SomeEarly Many Zero
       2.89% OnlyNotEarly_SomeEarly One Zero
       1.38% OnlyNotEarly_SomeEarly Many Many
       1.07% OnlyNotEarly_SomeEarly Many One
       0.08% OnlyNotEarly_SomeEarly Zero One

After:

ouroboros-consensus
  ChainSyncClient
    chainSync: OK (8.51s)                                                              
      +++ OK, passed 10000 tests:
      84.58% NoMoreIntersection
      10.51% ForkTooDeep
       0.62% RolledBackPastIntersection
      
      TickArrivalTimeStats (10000 in total):
      19.50% OnlyNotEarly_SomeEarly One Many
      16.81% OnlyNotEarly_SomeEarly One Zero
      15.85% OnlyNotEarly_SomeEarly Zero Many
      13.83% OnlyNotEarly_SomeEarly One One
      13.25% OnlyNotEarly_SomeEarly Many Zero
      10.58% OnlyNotEarly_SomeEarly Zero Zero
       5.39% OnlyNotEarly_SomeEarly Many Many
       4.79% OnlyNotEarly_SomeEarly Many One

Note that the NoMoreIntersection case is now significantly more common than the ForkTooDeep case, rather than the inverse.

Closes #529

[amesgen]

Can confirm that this achives the goal of #529:

Before #1201

      TickArrivalTimeStats (10000 in total):
      69.09% OnlyNotEarly_SomeEarly Zero Zero
      10.61% OnlyNotEarly_SomeEarly Zero Many
       5.89% OnlyNotEarly_SomeEarly One Many
       5.52% OnlyNotEarly_SomeEarly One One
       3.82% OnlyNotEarly_SomeEarly Many Zero
       2.70% OnlyNotEarly_SomeEarly One Zero
       1.26% OnlyNotEarly_SomeEarly Many Many
       1.01% OnlyNotEarly_SomeEarly Many One
       0.10% OnlyNotEarly_SomeEarly Zero One

With #1201

      TickArrivalTimeStats (10000 in total):
      18.16% OnlyNotEarly_SomeEarly One Many
      16.79% OnlyNotEarly_SomeEarly Zero Zero
      15.15% OnlyNotEarly_SomeEarly Zero Many
      14.41% OnlyNotEarly_SomeEarly One Zero
      13.38% OnlyNotEarly_SomeEarly One One
      12.87% OnlyNotEarly_SomeEarly Many Zero
       4.72% OnlyNotEarly_SomeEarly Many Many
       4.52% OnlyNotEarly_SomeEarly Many One

While better, the Zero Zero case still occurs ~17% of the time, so I guess startTick could be even smaller on average.

[amesgen]

LGTM

Needs eg an empty force push to make the changelog CI check go green after Javier added the no changelog label (we should at some point try to make this check be triggered by label changes).