Scoru: harden the levels processed in a commitment

Context

Closes #4352 (closed)

A commitment period right now look like:

0  <- origination level, you don't execute messages for this level
    1  2  3  4  5  6  7  8  9 10    |
   11 12 13 14 15 16 17 18 19 20    |-> 29 levels
   21 22 23 24 25 26 27 28 29       |
  v commitment level, you execute 30 in **the next commitment period**
30 31 32 33 34 35 36 37 38 39 40    |
   41 42 43 44 45 46 47 48 49 50    |-> 30 levels
   51 52 53 54 55 56 57 58 59       |

So you have in fact 29 levels for the first period then 30 for each, but now:

0  <- origination level, you don't execute messages for this level
   1  2  3  4  5  6  7  8  9 10    |
  11 12 13 14 15 16 17 18 19 20    |-> 30 levels
  21 22 23 24 25 26 27 28 29 30    |
   ^ commitment level, you execute 30 in **this commitment period**
  31 32 33 34 35 36 37 38 39 40    |
  41 42 43 44 45 46 47 48 49 50    |-> 30 levels
  51 52 53 54 55 56 57 58 59 60    |
   ^ commitment level, you execute 60 in **this commitment period**

So now all commitments periods are 30 made of levels.

Manually testing the MR

The cut at level should be unit-tested for the lower/upper bound of cut_at_level. The pbt should now both test the lower and upper bound with the Keen and Nostalgic strategies

Others tests remain to be fixed with the new limit on posting commitments.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• n/a Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• n/a For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR