Turn NoPruneContracts into DepositContract

[yperbasis]

Since EIP-6110 requires deposit contract address in the config, and the NoPruneContracts logic was used only for deposit contracts, it makes sense to turn NoPruneContracts into DepositContract.

[somnathb1]

• Deposit contract is only relevant to Ethereum and Ethereum-like chains, others may use more than one such contract and/or different naming.
• Even though it isn't a directly requested feature, there may be other contracts important to the node runner and/or L2's.
• The plan is to be able to add other contracts to this list in future. This PR is restricting that extensibility.

Further, the noPruneContracts list is for just that - not pruning logs of those contracts. Putting deposit contract against it is saying you can't have a deposit contract in the config without it not being pruned. For, let's assume that the CL no longer needs historical deposit contract logs in CHAIN1, that would mean removing this functionality altogether, or adding another flag for CHAIN2, CHAIN3... that says "dontPruneDepositLogs" or something - circling all the way back.

[yperbasis]

• Deposit contract is only relevant to Ethereum and Ethereum-like chains, others may use more than one such contract and/or different naming.
• Even though it isn't a directly requested feature, there may be other contracts important to the node runner and/or L2's.
• The plan is to be able to add other contracts to this list in future. This PR is restricting that extensibility.

Further, the noPruneContracts list is for just that - not pruning logs of those contracts. Putting deposit contract against it is saying you can't have a deposit contract in the config without it not being pruned. For, let's assume that the CL no longer needs historical deposit contract logs in CHAIN1, that would mean removing this functionality altogether, or adding another flag for CHAIN2, CHAIN3... that says "dontPruneDepositLogs" or something - circling all the way back.

Yes, I understand, but my preference is for simplicity over generality, especially when we don't have a strong ask for such extended functionality.

[yperbasis]

But OK, let me redo it slightly and leave the logic generic.

[somnathb1]

Granted that for now, deposit contract should be added to the noPruneContracts (in Ethereum-like chains) - this shouldn't be hard-coded in the flow, when we didn't need to.
Now, it's overall neither simple nor is the config of Deposit contract separate from pruning logic.

[yperbasis]

Granted that for now, deposit contract should be added to the noPruneContracts (in Ethereum-like chains) - this shouldn't be hard-coded in the flow, when we didn't need to. Now, it's overall neither simple nor is the config of Deposit contract separate from pruning logic.

OK, I'll revert to the simpler original version then. What I want to avoid is having duplicate NoPruneContracts & DepositContract in chain configs. And we de need DepositContract for EIP-6110. We can revisit this if we decide to extend the no prune logic to non-deposit contracts, but currently it doesn't look like a priority.

[somnathb1]

One more point: we are shifting our approach anyways with Erigon3, which will not have the logs pruning logic. 6110 will be a part of Erigon3, i presume.

[yperbasis]

As discussed, will merge after the switch to e3

[yperbasis]

I've rebased this to e3 and created a follow-up Issue #10153. @somnathb1 @racytech please approve