Use of calculatePoolDistr on the epoch boundary

Large computations on the epoch boundary are problematic. In the past they have lead to delayed block production in new epochs. For this reason, we have made the reward calculation and the (per stake credential) stake distribution calculation incremental. At least one remaining epoch boundary calculation remains, however, that we should consider handling in a better way, namely the per-stake-pool stake distribution calculation, performed by `calculatePoolDistr` in the `NEWEPOCH` transition.

Note that the consensus layer calls the `TICK` rule when processing block headers. This rule is usually pretty trivial, but when a block header corresponds to the first block of a new epoch, this rule includes extra work for the epoch boundary. When nodes are at the end of an epoch, and are trying to determine if they can make the first block of the next epoch, the `TICK` rule can be called multiple times. This can exacerbate situations like https://github.com/input-output-hk/cardano-node/issues/4421.

Even though `calculatePoolDistr` is called on the epoch boundary, the data that it uses for the calculation has been stable for a long time (`7k/f`-many slots).

We should consider calculating the per-stake-pool stake distribution well in advance of the epoch boundary, so that it is guaranteed to only every be computed once.