Refactor OfflinePruner to Use Local Interfaces for Database Access

[EmilGeorgiev]

Issue summary

In the OfflinePruner struct, the fields inputDB and filterDatabase are of type database.Database. The database.Database interface contains many methods, but OfflinePruner does not need all of them. Specifically, filterDatabase only needs Get() and Put(), while inputDB only needs Close().

type OfflinePruner struct {
    inputDB        database.Database
    storageState   *InmemoryStorageState
    blockState     *BlockState
    filterDatabase database.Database
    bestBlockHash  common.Hash
    retainBlockNum uint32

    inputDBPath string
}

It is better to define two local interfaces that contain only the methods needed. The benefits of this approach include:

1. Following Best Practices: Adheres to guidelines from the Go community
2. Interface Segregation Principle:Ensures that clients only depend on the methods they use, promoting a cleaner and more modular design.
3. Principle of Least Privilege: Reduces access to only necessary methods, minimizing potential for misuse and improving security. Principle of Least Privilege.
4. Reduced External Dependency: Avoids coupling OfflinePruner to the entire database.Database interface, making it resilient to future changes in the database.Database interface.
5. Ensuring Focused Functionality: Prevents types or classes from being burdened with unnecessary functionality.
6. Reduces Complexity: Smaller, focused interfaces are easier to understand and maintain.
7. Enhances Security:Limiting access to only required methods reduces the risk of accidental misuse.
8. Improves Robustness: Fewer methods mean fewer opportunities for bugs or errors.
9. Facilitates Testing: Smaller interfaces are easier to mock and test because there are fewer methods to simulate.

Related Issues:

3975

[EmilGeorgiev]

If you think this makes sense, can I take this issue?