feat: post horizon transition period clean up

[tmigone]

This PR removes code that's no longer relevant after the transition period.

In order for these changes to be valid there are some assumptions about the network state that must hold:

1. There are no more legacy allocations open. This can be guaranteed by force closing allocations, which can be done permisionlessly 28 days after Horizon go live.
2. Legacy allocation ids have been fully migrated to the SubgraphService. This is a privileged account operation that will be executed once Horizon is live and legacy allocations can no longer be created.
3. All service provider legacy unstake operations must be fully thawed. This needs to be monitored but it's also guaranteed as long as the transition period is longer than 28 days.

---

Note that contracts package tests are failing due to removing the staking contract as a valid rewards issuer from the RewardsManager. A deeper refactor of the package is required to fix this, most contracts in the contracts package are now deprecated so it's likely we need to extract those that are not into horizon package or a brand new one.

[openzeppelin-code]

feat: post horizon transition period clean up

Generated at commit: c4198504b1a9a099d8d2455692add600ea8dfc7d

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 5 0 14 38 59
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.18%. Comparing base (380f6ad) to head (c419850).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1261      +/-   ##
==========================================
+ Coverage   84.05%   84.18%   +0.12%     
==========================================
  Files          42       42              
  Lines        2070     2068       -2     
  Branches      615      613       -2     
==========================================
+ Hits         1740     1741       +1     
+ Misses        330      327       -3     

Flag	Coverage Δ
unittests	84.18% <100.00%> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RembrandtK]

Worth noting this is expected to happen after the RewardsManager is upgraded for REO and IA, but that upgrade is not included on main yet. Not sure if you want to base on main and subsequently adjust, or instead make relative to an issuance related branch that is anticipated to be closer to what the changes will be relative to?

[RembrandtK]

Simply sp.tokensStaked -= _tokens? (Intermediate stakedTokens no longer needed?)

[tmigone]

good catch

[RembrandtK]

So presumed in this scenario they are no longer locked although not yet withdrawn?

[tmigone]

yes, thats something we need to actually verify before deploying, though it should be true if the transition period is greater than the legacy thawing period (which is going to be)

[RembrandtK]

The use of __DEPRECATED prefix might be misleading, because although no longer intended to be the main flow, in many cases the variables are still being used and have valid values that can still be updated. Not sure if or how to change, it might be another prefix (__LEGACY) could be used for this scenario? You could argue 'deprecated' does mean this, but I think for the rest of the code it generally implies 'no longer used', representing a field that could (for example) be repurposed?

[Maikol]

We should also delete the files in subgraphService/test/integration/during-transition-period/

[Maikol]

nit: very minor but I would remove the new and have it (for allocations)

[Maikol]

So we'll be deploying these changes after the transition period plus 28 epochs?

[tmigone]

we only need go live + 28 epochs no? undelegations during the transition period are horizon undelegations already

[Maikol]

For undelegation yes but unstaking will still use the legacy method until the transition period ends. By go live do you mean when the transition period ends?