fix: correct epoch counting

[Cifko]

Description

Fix the epoch counting.

Motivation and Context

When the epoch length changed it affected the history as well. E.g. when you have epoch length set to 10 and it's height 1000. then the epoch # is 100. But when there is new consensus constant from 1001 with epoch length 20. Suddenly the epoch is 50.
Now it computes it like this:
When there is an constant change then it's effect is immediate but the epoch skip is prevented.
e.g.

1. Length is 15 and it's going to change on height 100 to 3. So on height 99 the epoch is 6, on 100 the epoch is 10 (because the current epoch is already of size 10).
2. Length is 15 and it's going to change on height 100 to 20. So on height 99 the epoch is 6, on 105 (without the change this would be the next epoch height, but with current new constant it's not changed). The epoch is changed on 110 (to 7).

Fixes tari-project/tari-dan#832

How Has This Been Tested?

There is a new test test_epoch_to_height_and_back

What process can a PR reviewer use to test or verify this change?

cargo.exe +stable test --package tari_core --lib -- consensus::consensus_manager::tests::test_epoch_to_height_and_back --exact --nocapture

Breaking Changes

• None
• Requires data directory on base node to be deleted
• Requires hard fork
• Other - Please specify
  This will break 2nd layer ONLY on chains that have new consensus constants.

[github-actions]

Test Results (CI)

    3 files    107 suites   34m 52s ⏱️
1 297 tests 1 296 ✅ 0 💤 1 ❌
3 219 runs  3 218 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit b6ac656.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results (Integration tests)

32 tests   32 ✅  12m 19s ⏱️
11 suites   0 💤
 2 files     0 ❌

Results for commit b6ac656.

♻️ This comment has been updated with latest results.

[SWvheerden]

A few small nits

[hansieodendaal]

Looks good (tested). Just some defence-in-depth comments.

[hansieodendaal]

utACK