fix: limit the max size of lending item extradata can be inside the t…

[wjrjerome]

Proposed changes

This PR is to fix the issue with no checking on the extradata field inside the trading and lending payload.

II'm taking the best guess based on the implementation of the extradata inside the trading and lending codebase.
The extraData can be one of the following data:

// from XDCxLending.go
extraData, _ := json.Marshal(struct {
	Price *big.Int
}{
        Price: XYZ,
})
// OR, from the `liquidationData` inside the same file (can also be found in order_processor.go)
liquidationData := lendingstate.LiquidationData{
	RecallAmount:      common.Big0,
	LiquidationAmount: newTrade.CollateralLockedAmount,
	CollateralPrice:   collateralPrice,
	Reason:            lendingstate.LiquidatedByPrice,
}
extraData, _ := json.Marshal(liquidationData)

// OR from the order_process.go's cancelOrder
extraData, _ := json.Marshal(struct {
   CancelFee       string
   TokenPriceInXDC string
}{
   CancelFee:       tokenCancelFee.Text(10),
   TokenPriceInXDC: tokenPriceInXDC.Text(10),
})

Based on the above struct, we can see the liquidationData is likely be the one with max length in payload.
I made theaAssumptions that each numeric value (RecallAmount, LiquidationAmount, CollateralPrice) is up to 30 digits long and the Reason field is 20 characters long, the estimated maximum size of the ExtraData JSON string in the ProcessLiquidationData function would be approximately 185 bytes.
Hence the value of 200 has been chosen to safeguard the block/tx in XDC in terms of sizes.

Types of changes

What types of changes does your code introduce to XDC network?
Put an ✅ in the boxes that apply

• Bugfix (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)
• Documentation Update (if none of the other choices apply)
• Regular KTLO or any of the maintaince work. e.g code style
• CICD Improvement

Impacted Components

Which part of the codebase this PR will touch base on,

Put an ✅ in the boxes that apply

• Consensus
• Account
• Network
• Geth
• Smart Contract
• External components
• Not sure (Please specify below)

Checklist

Put an ✅ in the boxes once you have confirmed below actions (or provide reasons on not doing so) that

• This PR has sufficient test coverage (unit/integration test) OR I have provided reason in the PR description for not having test coverage
• Provide an end-to-end test plan in the PR description on how to manually test it on the devnet/testnet.
• Tested the backwards compatibility.
• Tested with XDC nodes running this version co-exist with those running the previous version.
• Relevant documentation has been updated as part of this PR
• N/A

[liam-lai]

Can you put the math explanation at this comment please.

Based on the above struct, we can see the liquidationData is likely be the one with max length in payload.
I made theaAssumptions that each numeric value (RecallAmount, LiquidationAmount, CollateralPrice) is up to 30 digits long and the Reason field is 20 characters long, the estimated maximum size of the ExtraData JSON string in the ProcessLiquidationData function would be approximately 185 bytes.
Hence the value of 200 has been chosen to safeguard the block/tx in XDC in terms of sizes.