[CL Incentives] Add check to only sync uptime accums when necessary

[AlpinYukseloglu]

Background

We currently sync uptime accumulators before any operation that uses their values (e.g. tick init, tick crossing etc.). Since a single function is technically capable of triggering many of these updates, we are likely taking on redundant computation in the average case.

Suggested Design

• Add a check for LastLiquidityUpdate < ctx.Blocktime() before all uses of updateUptimeAccumulatorsToNow

Acceptance Criteria

• New and existing tests should pass

[p0mvn]

What if instead of having this function be executed in locations such as getTickInfo and crossTick, we move up this call higher in the execution flow? E.g. to updatePosition function or the swap-related functions.

That way, the accumulators will already be updated when logic that depends on the update such as getInitialUptimeGrowthOutsidesForTick is executed. At the same time, we avoid executing the same logic multiple times without the additional complexity surrounding each call to updateUptimeAccumulatorsToNow with last liquidity update checks.

Not sure if this is right but just another idea to explore - if updating these trackers is necessary for each block, maybe we have it in "begin block"?

[p0mvn]

ref: #4399 (comment)

[AlpinYukseloglu]

What if instead of having this function be executed in locations such as getTickInfo and crossTick, we move up this call higher in the execution flow? E.g. to updatePosition function or the swap-related functions.

Perhaps a simpler approach would be to rename getTickInfo to getOrInitTickInfo, much like what we have in other parts of the CL package.

Not sure if this is right but just another idea to explore - if updating these trackers is necessary for each block, maybe we have it in "begin block"?

We don't necessarily need to update every tracker for every tick each block. In fact, if a pool isn't touched for 1,000 blocks, the incentive accumulators should remain unchanged – this is by design! I think the approach suggested in the issue achieves the minimum number of calls possible all things considered.

[AlpinYukseloglu]

This was addressed in an earlier PR (we already skip accumulator updates if no time has elapsed)