SVP spend tx waiting for signatures default double serialization

[apancorb]

Description

In this PR we address a fix that was caught when running the powpeg-node locally. When there is no SVP spend tx waiting for signatures, the Bridge currently returns an single serialized empty array. The problem is that the DTO used (StateForProposedFederator) assumes that as its predecessor (StateForFederator) it should be double serialized. So this change also returns an empty double serialized array using the RLP format.

The error thrown by the listener in the powpeg-node:

2024-11-14-10:52:55.206 TRACE [c.r.f.BridgeTransactionSender]  Bridge call - method: getStateForSvpClient
2024-11-14-10:52:55.207 ERROR [events]  Listener callback failed with exception
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
        at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
        at java.base/java.util.Objects.checkIndex(Objects.java:385)
        at java.base/java.util.ArrayList.get(ArrayList.java:427)
        at org.ethereum.util.RLPList.get(RLPList.java:48)
        at co.rsk.peg.StateForProposedFederator.decodeRlpToEntry(StateForProposedFederator.java:66)
        at co.rsk.peg.StateForProposedFederator.<init>(StateForProposedFederator.java:44)
        at co.rsk.federate.FederatorSupport.lambda$getStateForProposedFederator$0(FederatorSupport.java:155)
        at java.base/java.util.Optional.map(Optional.java:260)
        at co.rsk.federate.FederatorSupport.getStateForProposedFederator(FederatorSupport.java:155)
        at co.rsk.federate.btcreleaseclient.BtcReleaseClient$BtcReleaseEthereumListener.onBestBlock(BtcReleaseClient.java:243)
        at org.ethereum.listener.CompositeEthereumListener.lambda$onBestBlock$2(CompositeEthereumListener.java:71)
        at org.ethereum.listener.CompositeEthereumListener.scheduleListenerCallbacks(CompositeEthereumListener.java:132)
        at org.ethereum.listener.CompositeEthereumListener.onBestBlock(CompositeEthereumListener.java:71)
        at co.rsk.core.bc.BlockChainImpl.onBestBlock(BlockChainImpl.java:513)
        at co.rsk.core.bc.BlockChainImpl.internalTryToConnect(BlockChainImpl.java:304)
        at co.rsk.core.bc.BlockChainImpl.tryToConnect(BlockChainImpl.java:158)
        at org.ethereum.facade.EthereumImpl.addNewMinedBlock(EthereumImpl.java:62)
        at co.rsk.mine.MinerServerImpl.processSolution(MinerServerImpl.java:346)
        at co.rsk.mine.MinerServerImpl.submitBitcoinBlock(MinerServerImpl.java:291)
        at co.rsk.mine.MinerServerImpl.submitBitcoinBlock(MinerServerImpl.java:285)
        at co.rsk.mine.MinerClientImpl.mineBlock(MinerClientImpl.java:146)
        at co.rsk.mine.MinerClientImpl.doWork(MinerClientImpl.java:102)
        at co.rsk.mine.MinerClientImpl$1.run(MinerClientImpl.java:88)

Motivation and Context

https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP419.md

How Has This Been Tested?

This has been tested locally in regtest. The powpeg-node is able to process new blocks without error when the SVP spend tx is not present.

Types of changes

• [ X] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• [X ] My code follows the code style of this project.
• My change requires a change to the documentation.
• [X ] I have updated the documentation accordingly.
• [ X] Tests for the changes have been added (for bug fixes / features)
• Requires Activation Code (Hard Fork)

• Other information:

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Manifest Files

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud