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).

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    120 suites   43m 50s ⏱️
1 280 tests 1 280 ✅ 0 💤 0 ❌
3 832 runs  3 832 ✅ 0 💤 0 ❌

Results for commit 7b41d15.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results (Integration tests)

 2 files  11 suites   12m 3s ⏱️
30 tests 29 ✅ 0 💤 1 ❌
31 runs  30 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 7b41d15.

♻️ 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