refactor: add index method for StacksEpochId

[obycode]

This allows us to cleanup some magic numbers when accessing epochs in a list and make the expected behavior more clear to the reader.

[jcnelson]

LGTM assuming CI passes

[obycode]

There was once place acting on a list of epochs where the list was incomplete, so the standard indices shouldn't be used. This fix should resolve the failing tests.

[kantai]

I think it'd be good to try to clean up the magic numbers and accessors used in epoch lists, but I'm kind of wary of encoding the indexes, even though it probably is perfectly safe (because there's no legal epoch ordering where 2.4 doesn't exist, but 2.5 does).

An alternative that I think would have some of the same benefits would be a wrapper struct...

pub struct EpochList (Vec<StacksEpoch>)

And then defining:

impl Index<&StacksEpochId> for EpochList {
  type Output = StacksEpoch;
  fn index(&self, index: &StacksEpochId) -> &StacksEpoch {
     self.get(index).unwrap()
  }
}

impl EpochList {
  fn get(&self, index: &StacksEpochId) -> Option<&StacksEpoch> {
     self.0.get(StacksEpoch::find_by_epoch_id(&self.0, index)?)
  }
}

Then, we could do things like epochs[StacksEpochId::Epoch30] for panicking uses, and epochs.get(Epoch30) for non-panicking uses

[obycode]

Sure, that does seem nice. Likely a little slower, but I don't think we'd use it anywhere that is performance critical.

[obycode]

Ok, re-refactored with pub struct EpochList (Vec<StacksEpoch>)

[kantai]

This looks good to me-- it definitely improves the legibility of the epochs lists! Just a couple comments.

[blockstack-devops]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.