removed zero error case in slash query

[sampocs]

Context

There's currently an error case that's preventing validator's with 0 delegations from having their slash queries reset. This check was only meant to protect against a division by zero error, but it's repeated downstream here in a more suitable place.

Really, there are 3 scenarios we could run into:

• Internal delegation is 0, delegation from query response is 0 (this is covered here) and will return successfully
• Internal delegation is 0, delegation from query response is slightly larger because of a precision error (this is covered here and corrects the precision error)
• Internal delegation is 0, delegation from query response is much larger - this would indicate an actual bug and the appropriate error is returned here

All that said, we don't need to throw the original error at the top of the function.

Brief Changelog

• Removed error case of a zero delegation
• Added unit test
• Updated existing unit tests to check the slash query in progress flag

[ethan-stride]

LGTM
So tracing through the paths -- removing this zero check will successfully reset the slashQueryInProgress flag on the hostZone but when it actually checks if a slash happened it will exit because it will get a zero == zero on the delegatedTokens.Equal(validator.Delegation) check inside of the CheckForSlash call, and importantly it will then exit with nil error so SlashValidatorOnHostZone will not get called.

So this also means that for validators with 0 delegation, even if they really were slashed, we can't detect it with our current methods because we are computing the weight from the delegation changes not able to ICQ the weight directly. If we have the wrong weight on a validator, when we actually add delegation what are the implications? Do we really only have to care about the multiplicative change over time as it relates to our delegations and not the absolute value of the weight for that validator?

(aside: in the precision error case why do we only check one sided? Could precision errors also cause a LT to happen but in a very small amount? Right now even a minuscule difference to the downside is interpreted as a slash)

[sampocs]

(aside: in the precision error case why do we only check one sided? Could precision errors also cause a LT to happen but in a very small amount? Right now even a minuscule difference to the downside is interpreted as a slash)

Discussed this in standup, but just to reiterate - any downward change is registered as a slash and automatically updated (regardless of the magnitude). The precision error check is only for the GT case because if the query response is much greater than our internal accounting - that indicates an actual error

So this also means that for validators with 0 delegation, even if they really were slashed, we can't detect it with our current methods because we are computing the weight from the delegation changes not able to ICQ the weight directly

That's right, but we would expect the query response also has 0 or represents a precision error case and is caught upstream.

[shellvish]

Thanks for doing this!

[sampocs]

@riley-stride are you signed off on this? I thought from axolo that it looked like you reviewed