Adding transaction_call endpoint

[otherview]

Description

This PR adds a new endpoint that allows to simulate and estimate based on transactions instead of clauses.
The added value is to bring api communication to the transaction level. This allows for gotchas like, chaintag, expiration, nonce, etc to be more visible and allows executing transactions in a given block revision

Summary of the endpoint:

URL :         POST /transactions/call?revision=best
Payload :   transaction.Transaction (existing type)
Response:   transaction.CallReceipt (transaction.Receipt minus Block info)
type CallReceipt struct {
	GasUsed  uint64                `json:"gasUsed"`
	GasPayer thor.Address          `json:"gasPayer"`
	Paid     *math.HexOrDecimal256 `json:"paid"`
	Reward   *math.HexOrDecimal256 `json:"reward"`
	Reverted bool                  `json:"reverted"`
	TxID     thor.Bytes32          `json:"txID"`
	TxOrigin thor.Address          `json:"txOrigin"`
	Outputs  []*Output             `json:"outputs"`
	VmError  string                `json:"vmError"`
}

Goal: Execute a transaction at the head of a specified block. Retrieve the total gas cost at the transaction level.
(Note: Can be expanded to execute in a block at a given tx position.)

Fixes # (issue)

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Tests

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• New and existing E2E tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have not added any vulnerable dependencies to my code

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 32.60274% with 246 lines in your changes missing coverage. Please review.

Project coverage is 60.33%. Comparing base (5867f22) to head (5c167fb).

Files with missing lines	Patch %	Lines
runtime/runtime.go	0.00%	107 Missing ⚠️
api/transactions/types.go	59.57%	34 Missing and 4 partials ⚠️
runtime/resolved_tx.go	0.00%	28 Missing ⚠️
api/transactions/transactions.go	63.51%	19 Missing and 8 partials ⚠️
api/metrics.go	4.16%	22 Missing and 1 partial ⚠️
tx/block_ref.go	0.00%	13 Missing ⚠️
thorclient/httpclient/client.go	57.14%	4 Missing and 2 partials ⚠️
thorclient/thorclient.go	70.00%	3 Missing ⚠️
api/api.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #832      +/-   ##
==========================================
- Coverage   60.81%   60.33%   -0.49%     
==========================================
  Files         220      220              
  Lines       23414    23763     +349     
==========================================
+ Hits        14240    14338      +98     
- Misses       8007     8241     +234     
- Partials     1167     1184      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

This pull request has been marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

To fix the reflected cross-site scripting vulnerability, we need to ensure that any user input is properly sanitized or escaped before being written to the HTTP response. In this case, we can use the html.EscapeString function from the html package to escape any potentially dangerous characters in the user input.

• We will modify the Write method in callTxResponseWriter to escape the user input before writing it to the response.
• Specifically, we will escape the VMError field in the resp struct before writing the response.

[leszek-vechain]

can we also add negative tests ?

[MakisChristou]

I guess we can but those are mock tests afaik. So not sure what the benefit of returning a hardcoded "error" response will be and checking if its what we expect.