vote: Use wrapping pow with min lockout history in lockout() calculation

[mjain-jump]

The default behavior in the vote lockouts calculation is to panic on larger confirmation counts. This case never gets hit in production / mainnet, but our fuzzers often hit this case when fuzzing at the instruction / transaction level and providing arbitrary confirmation counts within the account data. Since this case is incredibly difficult to prevent in the fuzzer's mutations, we choose to handle this behavior more gracefully by avoiding the panic due to overflow.

[jstarry]

This seems reasonable but I have a slight preference to saturating_pow because then lockouts from invalid conf counts would be a bit more apparent vs hidden with your current approach, @AshwinSekar thoughts?

[mjain-jump]

This seems reasonable but I have a slight preference to saturating_pow because then lockouts from invalid conf counts would be a bit more apparent vs hidden with your current approach, @AshwinSekar thoughts?

How about standard pow() with the min() call? With saturating operations you still run the risk of hitting overflow where the caller doesn't handle the return value properly, and it makes sense to constrain it to the maximum expected return value.

[AshwinSekar]

I'm fine with the min approach