refactor: simplify naming and logic in registries and registry coordinator

[wadealexc]

Motivation:

• fix word soup variable and function naming
• take advantage of new quorum existence invariant due to RegistryCoordinator.createQuorum and its associated initializeQuorum methods in each registry
• registries each keep "histories" of updates. The status quo is that every time anything changes, we push a new history update. this means that when updates happen multiple times in the same block, the history contains multiple updates from the same block number, making it harder to determine what the canonical state at a given block number is.

This PR:

• Replaces logic that handles "0-length histories" with simple checks, since we now have an invariant that initialized quorums have nonzero histories (see any registry's initializeQuorum method)
• changes registry histories to update their "most recent entry" rather than pushing a new entry, if the entry was made in the current block
• Renames state variables in the registry coordinator and registry contracts to be less wordy

For reviewers, this order may work best:

1. Review IndexRegistry changes in the first commit, which contains the functional changes mentioned above, as well as readability/logical simplification. This is the worst commit to review, sorry! The diff looks intimidating, so I'd recommend opening the new/old IndexRegistry files side by side and comparing like that. 🙏
2. The rest of the commits are style/refactor commits. I'd recommend skimming the renaming changes below and only dipping into the commits themselves if you feel like it.

Renaming changes:

• IndexRegistry state vars:
  • operatorIdToIndex -> currentOperatorIndex
  • _totalOperatorsHistory -> _operatorCountHistory
  • _indexToOperatorIdHistory -> _indexHistory
• IndexRegistry functions:
  • _getTotalOperatorsForQuorumAtBlockNumber -> _operatorCountAtBlockNumber
  • _getOperatorIdAtIndexForQuorumAtBlockNumber -> _operatorIdForIndexAtBlockNumber
  • getOperatorIndexUpdateOfIndexForQuorumAtIndex -> getOperatorUpdateAtIndex
  • getTotalOperatorsForQuorumAtBlockNumberByIndex -> getTotalOperatorsForIndexAtBlockNumber
  • getOperatorListForQuorumAtBlockNumber -> getOperatorListAtBlockNumber
• StakeRegistry state vars:
  • operatorIdToStakeHistory -> operatorStakeHistory
  • strategiesConsideredAndMultipliers -> strategyParams
• StakeRegistry structs:
  • StrategyAndWeightingMultiplier -> StrategyParams
• StakeRegistry functions:
  • strategiesConsideredAndMultipliersLength -> strategyParamsLength
  • strategyAndWeightingMultiplierForQuorumByIndex -> strategyParamsByIndex
  • getOperatorIdToStakeHistory -> getOperatorStakeHistory
  • getLengthOfTotalStakeHistoryForQuorum -> getTotalStakeHistoryLength
  • getTotalStakeUpdateForQuorumFromIndex -> getTotalStakeUpdateAtIndex
  • getStakeUpdateIndexForOperatorIdForQuorumAtBlockNumber -> getStakeUpdateIndexForOperatorAtBlockNumber
  • getTotalStakeIndicesByQuorumNumbersAtBlockNumber -> getTotalStakeIndicesAtBlockNumber
  • getStakeUpdateForQuorumFromOperatorIdAndIndex -> getStakeUpdateForOperatorAtIndex
  • getStakeForQuorumAtBlockNumberFromOperatorIdAndIndex -> getOperatorStakeAtBlockNumberAndIndex
  • getStakeForOperatorIdForQuorumAtBlockNumber -> getOperatorStakeAtBlockNumber
  • getLengthOfOperatorIdStakeHistoryForQuorum -> getOperatorStakeHistoryLength
• BLSRegistryCoordinatorWithIndices state vars:
  • _quorumOperatorSetParams -> _quorumParams
  • _operatorIdToQuorumBitmapHistory -> _operatorBitmapHistory
  • _operators -> _operatorInfo
• BLSRegistryCoordinatorWithIndices state modifying functions:
  • registerOperatorWithCoordinator -> registerOperator
  • registerOperatorWithCoordinator -> registerOperatorWithChurn
  • deregisterOperatorWithCoordinator -> deregisterOperator
  • ejectOperatorFromCoordinator -> ejectOperator
• BLSRegistryCoordinatorWithIndices view functions:
  • getQuorumBitmapIndicesByOperatorIdsAtBlockNumber -> getQuorumBitmapIndicesAtBlockNumber
  • getQuorumBitmapByOperatorIdAtBlockNumberByIndex -> getQuorumBitmapAtBlockNumberByIndex
  • getQuorumBitmapUpdateByOperatorIdByIndex -> getQuorumBitmapUpdateByIndex
  • getCurrentQuorumBitmapByOperatorId -> getCurrentQuorumBitmap
  • getQuorumBitmapUpdateByOperatorIdLength -> getQuorumBitmapHistoryLength

IndexRegistry changes:

• Refactored index registry history updates to have a more readable register/deregister flow:
  • registerOperator is now _increaseOperatorCount + _assignOperatorToIndex. Functional changes:
    • If the most recent QuorumUpdate/OperatorUpdate is from this block, we update the last entry rather than pushing a new one.
  • deregisterOperator is now _decreaseOperatorCount + _popLastOperator + _assignOperatorToIndex. Functional changes:
    • As above, histories are updated rather than pushed if the last entry was from the current block.
    • Previously, we assigned currentOperatorIndex[quorum][OPERATOR_DOES_NOT_EXIST_ID] to the removed index, and emitted an event for this update. This logic has been removed, since the currentOperatorIndex of the null id doesn't matter. See previous logic vs new logic

[gpsanant]

revert if 0

[wadealexc]

I need to add an explicit comment about this, but this method assumes the quorum exists. all calling locations already perform this check, and will revert higher in the stack if it's caught - so we don't necessarily need an explicit check here.

updateStakes doesnt currently check this, but i'm moving that out of this contract anyway.

[gpsanant]

_getLatestQuorumUpdate? same below?

[ChaoticWalrus]

seems unrelated to this PR(?) but I think calling this struct 'QuorumUpdate' is super vague. It should probably be an 'OperatorCountUpdate' or something similar

[ChaoticWalrus]

IndexRegistry looking good, really liking the changes to it overall; I added some comments but I don't think anything is big, just nits or discussion points. Will be proceeding with remainder of review.

[ChaoticWalrus]

should we maybe do this earlier in this function?
seems like a fairly late revert condition, but I guess those are somewhat difficult to avoid in this design overall.

[wadealexc]

yes :)

i'm doing this in a future PR

[ChaoticWalrus]

should we perhaps name the struct 'OperatorInfo' as well?

[wadealexc]

+1. Will make this change in a future pr.

[ChaoticWalrus]

here we are still pushing an update, as opposed to modifying the previous update (if the block number is the same).
seems fine to implement later, just pointing this out

[ChaoticWalrus]

I see TODOs elsewhere so only called out this location

[ChaoticWalrus]

Changes LGTM.
Feels fine to merge this as-is; I looked through everything and don't have any substantive issues, mostly just suggestions for further changes.