WIP: Initial window downtime slash fix

[joe-bowman]

• [+] Updated all relevant documentation (docs/) - overall behaviour hasn't deviated from that documented.
• [+] Updated all relevant code comments
• [+] Written tests
• [+] Added entries in PENDING.md
• [+] Updated cmd/gaia and examples/ - no change

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #1792 into develop will decrease coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop    #1792      +/-   ##
===========================================
- Coverage    63.46%   63.44%   -0.02%     
===========================================
  Files          117      117              
  Lines         6914     6919       +5     
===========================================
+ Hits          4388     4390       +2     
- Misses        2270     2272       +2     
- Partials       256      257       +1

[rigelrozanski]

Link to forum conversation:
https://forum.cosmos.network/t/slashing-logic-for-vote-signing/567/5

As I mentioned in the forum:

Interesting point, as far as I understand the reason why this logic only begins to consider after the minHeight is because before that height you have not been signing whatsoever. This means if we were simply to adapt this logic to exclude the height > minHeight statement then the validator would always get slashed immediately after they bonded (because at their first block of being a validator they will have not met the minimum votes, because they just started!). One way to mitigate this would be to perform a different calculation for new validators at different increments, (aka take percentage calculations). The major downside of this is that this calculation is extremely sensitive to number of computations as it must be called once per block PER validator (aka. 100 times per block)
I ultimately don’t think this is an attack vector because we’ve discussed that fee-rewards/provisions should only begin to be accrued past this liveliness period (40000 blocks in this example) period meaning that if you were to not be signing and then you unbonded your tokens, you would not be at any advantage because you will have not been able to collect any rewards in that period.

Aka. I'm not sure if we want this, good to get @cwgoes input though

---

Also for future reference this PR has not followed a general procedure from contributing which is to open up a proposal github issue with a suggested design before writing code... we just don't want anyone to waste time when the code will potentially not be used! To our foley, I just reviewed the contributing guidelines and I'll note that this information isn't clearly and explicitly stated, I'm going to address that now.

For the time being let's use this pull request to discuss this potential issue, but we may (not necessarily!) have to scrap or rewrite this code depending on the conclusions we arrive at!

edit: chris thinks you wrote good tests :)

[cwgoes]

Thanks for the PR (and FWIW I think it's very well-written).

Let's discuss the desired behavior a bit more first - see this post.

[rigelrozanski]

Should be merged into a reference branch @cwgoes

[rigelrozanski]

closing saved to reference branch for later implementation in rigel/REFERENCE-1792-initial-window-downtime-slash

[rigelrozanski]

Ref #2480