chore: add rewards v2.2 comprehensive unit/integration/Anvil tests

[serichoi65]

Description

Summary

Adds comprehensive unit, integration, and Anvil tests for Rewards v2.2 (PRs #476, #481), validating operator allocation snapshots, withdrawal queue logic, and refund calculations. All tests passing with 100% coverage of edge cases defined in the Rewards V2.2 Testing Plan.

Test Coverage

OAS (Operator Allocation Snapshots) - 17 scenarios:

• OAS-1 to OAS-3: Basic allocation rounding (UP for allocations, DOWN for deallocations)
• OAS-4 to OAS-9: Same-day allocation changes, effective block delays
• OAS-10 to OAS-14: Max magnitude updates, slashing simulations
• OAS-15 to OAS-17: Multi-strategy allocations, future block scenarios

SSS (Staker Share Snapshots) - 15 scenarios:

• SSS-1 to SSS-7: Withdrawal queue timing (14-day delay)
• SSS-8 to SSS-11: Slashing during withdrawal queue
• SSS-12 to SSS-15: Same-block events (withdrawal + slash log ordering), dual slashing

R (Refunds) - 4 scenarios:

• R-1: Full period refund (no allocation)
• R-2: Partial refund (allocation starts mid-period)
• R-3: Post-deallocation refund
• R-4: Multi-operator proportional distribution

Integration Tests (8 Scenarios - PostgreSQL):

• Scenario 1: Forward-looking rewards with withdrawal during period
• Scenario 2: Multiple concurrent withdrawals
• Scenario 3: Slash during withdrawal queue
• Scenario 4: 2-year forward-looking rewards
• Scenario 5: Deallocation queue (operator unique stake)
• Scenario 6: Undelegation with slashing (TC4)
• Scenario 7: Withdrawal queue with deallocation
• Scenario 8: Withdrawal completing at reward period end

Anvil Tests (10 Scenarios - Real Contract Events):

• Tier 2 and Tier 3 tests with actual AllocationManager events
• Validates event ingestion and snapshot generation
• Configured for PreprodHoodi environment

Bug Fixes & Improvements

Schema Corrections:

• Fixed blocks table inserts (removed non-existent columns)
• Fixed operator_allocations inserts (removed avs_directory, block_time)
• Fixed staker_shares inserts (aligned with migration schema)
• Fixed reward_submissions and operator_set_operator_registrations schemas

Snapshot Timing Logic:

• Corrected off-by-one errors (events on 1/5 appear in 1/6 snapshot)
• Fixed withdrawal queue timing (14-day inclusive/exclusive logic)
• Adjusted all test expectations to match block_date < snapshot_date logic

Linter Fixes:

• Fixed unchecked error returns in rewardsV2_2_anvil_test.go (10 instances)
• Removed unused variables across test files
• Fixed timezone comparison issues (using formatted strings)

Chain Configuration:

• Updated all tests to use Chain_PreprodHoodi
• Verified Sabine fork configuration (1970-01-01 for preprod environments)

Notes

• Legacy tests in stakerShareSnapshots_test.go intentionally skipped (incompatible with continuous daily snapshot generation)
• Test database automatically created/dropped for isolation
• Anvil tests require REWARDS_COORDINATOR_ADDRESS and ALLOCATION_MANAGER_ADDRESS environment variables

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Chore (non-breaking change which does not add functionality)

How Has This Been Tested?

Unit tests

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[anupsv]

is the source of the .withdrawalQueueWindow from event emission ?

[serichoi65]

The withdrawalQueueWindow is a configuration value (r.globalConfig.Rewards.WithdrawalQueueWindow), not from event emission. It's set to 14 days for mainnet.

[ypatil12]

Since this query is selecting from queued_slashing_withdrawal table, which hasn't been committed yet (ie. latest block not updated), could we have a staleness issue? Edge case: a withdrawal has been queued in this block and then we are slashed a couple times in the same block. Do we need to add accumulated withdrawals in the given block? cc @elhajin