refactoring(share): Move Pruner Interface to Availability Package

[walldiss]

Implementation ideas

Proposal to relocate the Pruner interface to the Availability package to enhance cohesion between components that manage data lifecycle within the node. This change aims to align both pruning and data availability functionalities which are inherently related, albeit performing opposite tasks.

The Pruner and Availability functionalities are closely tied, as they manage different aspects of data lifecycle - storage and removal, respectively. Combining them under the same package will:

• Improve Cohesion: Both interfaces deal with node type-specific behaviors. Housing them in the same package emphasizes their interrelated roles.
• Facilitate Access to Shared Context: This move will allow the pruner components to have better awareness of the implementation details of data availability, potentially optimizing the data pruning process.
• Maintain Modular Design: Despite the proposed integration at the interface level, the Pruner service will continue to reside in its own separate package, maintaining a clean separation of concerns similar to how the DASer is structured.

[walldiss]

Just a quick add-on: If we move the Pruner interface to the same package as Availability, there’s a another benefit. Availability could be aware of the pruner settings and skip availability calls internally instead of exporting it to DASer. This way, availability benefit from pruner (smart skip) and pruner benefits from availability (smart delete). They become more efficient together.

[Wondertan]

👍 to the proposal.
Also, pruner shouldn't be its own module on the nodebuilder, but a part of a share module.

[nodersteam]

Hello @Wondertan @walldiss @renaynay can we take this issue?

[Wondertan]

This is purely a refactoring issue that requires a lot of context to be done right. I wouldn't recommend working on it, especially since Shwap is in progress