enable stake table epochs

[alysiahuggins]

Closes #2505

This PR:

• re-adds epoch functionality so that validator registrations and exits can be handled on a epoch basis
• ensures that the currentEpoch is a based on the latest hotshot block height and the hotShotBlocksPerEpoch
• the hotShotBlocksPerEpoch is set at constructor time
• consolidates nextRegistraionEpoch() and nextExitEpoch() into one function, nextAvailableEpoch(...) since the logic was the same
• adds tests for the currentEpoch() and nextAvailableEpoch(...) functions

This PR does not:

• provide a way to update hotshot blocks per epoch as it's assumed that this will not change in the near future, when it does change the function can be updated
• handle integer overflows (e.g. currentEpoch()+1) - this is a discussion to have
• modify epoch logic for functions such as withdrawFunds() which depends on the epoch functionality, this will be handled in other github issues.

Key places to review:

[sveitser]

provide a way to update hotshot blocks per epoch as it's assumed that this will not change in the near future, when it does change the function can be updated

If the blocks per epoch changes then the computation of current epoch becomes more complicated and we need to store the original value of blocks per epoch and the new value to compute epochs correctly as a function of the hotshot block height. I wonder if we should make the blockPerEpoch an array of (hotshotBlockNumber, blocksPerEpoch) to enable this computation.

[alysiahuggins]

provide a way to update hotshot blocks per epoch as it's assumed that this will not change in the near future, when it does change the function can be updated

If the blocks per epoch changes then the computation of current epoch becomes more complicated and we need to store the original value of blocks per epoch and the new value to compute epochs correctly as a function of the hotshot block height. I wonder if we should make the blockPerEpoch an array of (hotshotBlockNumber, blocksPerEpoch) to enable this computation.

great idea, we discussed this and concluded that we didn't need to support changing hotshot blocks per epoch at this moment. but we could do, @jbearer @bfish713 what do you think?

[sveitser]

Add a comment as to why we don't need to worry about overflow?

[alysiahuggins]

i added it as a todo in line 174, i want to start a discussion around this, will do so now

[alysiahuggins]

so they don't handle overflow in the offchain code, so i think a revert if it overflows can work? though it's a check every time this is invoked. what do you think?

[sveitser]

I think the test would be easier to read if it just hardcoded zeroes, wherever zero is expected.

[alysiahuggins]

makes sense, updated here af8841c

[sveitser]

I meant more generally l if we use asserts in a test it's usually implied that we are asserting that some value is equal to an expected value. So instead of assert(epoch, expectedEpoch) we can write assert(epoch, 0) and end up with fewer indirections.

However, if the left and right hand size are some complicated expressions then defining some extra variables is helpful for reading.

[sveitser]

There is the comment above how _numPendingRegistrations is not the total queue size.

espresso-sequencer/contracts/src/StakeTable.sol

Lines 89 to 91 in 0728068

	/// @notice number of pending registrations in the `firstAvailableRegistrationEpoch` (not the
	/// total pending queue size!)
	uint64 private _numPendingRegistrations;

But later we set it as such, although there is also a TODO in that comment

espresso-sequencer/contracts/src/StakeTable.sol

Lines 213 to 219 in 0728068

	// @param queueSize current size of the registration queue (after insertion of new element in
	// the queue)
	/// TODO modify this according to the current spec
	function appendRegistrationQueue(uint64 epoch, uint64 queueSize) private {
	firstAvailableRegistrationEpoch = epoch;
	_numPendingRegistrations = queueSize + 1;
	}

I think it would be nice if we named things a bit more explicitly. Since there are many epochs, queue sizes, etc. especially for those variables it's useful to be explicit.