[CL]: Investigate feasibility of bounding min/max price to avoid any use of canonical ticks

[AlpinYukseloglu]

Background

The notion of "canonical ticks" at the extreme ends of our supported prices is one of the primary sources of loss of monotonicity in our tick to sqrt price conversions (the other being our non-monotonic ApproxRoot function, which is described in #5517 and more easily fixable).

Given how the issue only seems to arise at ticks that are close to our MinTick, we should investigate whether it can be avoided altogether by simply moving this value slightly higher.

Suggested Design

• Find the first tick where canonical ticks become an issue (in either direction, but I believe it should only apply for smaller prices)
• See how much the corresponding minimum supported price would need to be moved to avoid canonical ticks
• If the final price is smaller than 10^-14 (Coingecko's min price), then move it and remove canonical tick logic

Acceptance Criteria

• All new and existing tests should pass
• Monotonicity sanity tests should be added around bounds

[p0mvn]

AFAIK, this is now addressed. Can we close this?

[AlpinYukseloglu]

Yep!