chore!: update ADR-05 and leverage keeper cosmetic updates

[robert-zaremba]

Description

• updated ADR 05 (liquidation) document
• renamed CalculateLiquidationLimit -> CalculateLiquidationThreshold. The function return the maximum amount in USD we can borrow. Not a limit of a liquidation.
• Updated error messages and style.

related to: #897

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added appropriate labels to the PR
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[toteki]

renamed CalculateLiquidationLimit -> CalculateMaxBorrow.

Reconsider this, as the maximum a user can borrow is BorrowLimit.

MaxBorrow sounds too much like that.

[robert-zaremba]

Reconsider this, as the maximum a user can borrow is BorrowLimit.

@toteki how about LiquidationThreshold?

[robert-zaremba]

renamed rename CalculateMaxBorrow to CalculateLiquidationThreshold

[toteki]

What's left to do is fix the failing CI.

Note that with the client tests appearing before

FAIL	github.com/umee-network/umee/v2/x/leverage/client/tests	313.516s

that they execute in series without resetting the keeper, meaning the first failure (e.g. a Liquidate not working) will mean more failures (e.g. the borrower having an unexpected borrowed_value) in the next tests.

For that test, always fix the first error to print before checking the others.

[robert-zaremba]

I've updated the test. The bug was in maxCollateral: was using desiredReward.Denom rather than k.ExchangeToken(ctx, baseReward).Denom. The difference is that the latter is a u/ token and the former is not.

[codecov-commenter]

Codecov Report

Merging #903 (a4625b8) into main (d3546fd) will decrease coverage by 0.03%.
The diff coverage is 47.29%.

@@            Coverage Diff             @@
##             main     #903      +/-   ##
==========================================
- Coverage   50.90%   50.87%   -0.04%     
==========================================
  Files          64       64              
  Lines        9456     9451       -5     
==========================================
- Hits         4814     4808       -6     
  Misses       4397     4397              
- Partials      245      246       +1     

Impacted Files	Coverage Δ
x/leverage/client/cli/query.go	0.00% <0.00%> (ø)
x/leverage/keeper/grpc_query.go	5.55% <0.00%> (ø)
x/leverage/types/query.pb.gw.go	0.00% <0.00%> (ø)
x/leverage/keeper/keeper.go	46.63% <51.51%> (-0.91%)	⬇️
x/leverage/client/tests/suite.go	100.00% <100.00%> (ø)
x/leverage/keeper/borrows.go	77.45% <100.00%> (ø)
x/leverage/keeper/iter.go	54.97% <100.00%> (ø)

[toteki]

Should we also update the query whose url is liquidation_limit to liquidation_threshold?

Ready to approve on all other fronts - we just need to clean up any references to the old term.

Note that liquidation threshold was the original name of the concept, but it got renamed to liquidation limit when the Token struct's collateral_weight param split into collateral_weight and liquidation_threshold to allow a buffer between borrow limit and liquidation eligibility.

As long as we're ok with that ambiguity, we can proceed.