Enhance rholang execution error message

[zsluedem]

Overview

when you deploy a contract like below

new blockData(`rho:block:timestamp`), stdout(`rho:io:stdout`), retCh in {
  blockData!(*retCh) |
  for(@blockNumber, @timestamp, @sender <- retCh) {
      stdout!({"block number": blockNumber}) |
      stdout!({"block time": timestamp})|
      stdout!({"block sender": sender})
  }
}

no matter how much phloLimit you put in the deploy, the node would always consume all the phlos because blockData('rho:block:timestamp') is not a valid system process.

The deployInfo in the block should be like below

{
"deployer": "xxxxx",
"term": "\nnew blockData(`rho:block:timestamp`), stdout(`rho:io:stdout`), retCh in {\n  blockData!(*retCh) |\n  for(@blockNumber, @timestamp, @sender <- retCh) {\n      stdout!({\"block number\": blockNumber}) |\n      stdout!({\"block time\": timestamp})|\n      stdout!({\"block sender\": sender})\n  }\n}\n",
"timestamp": 1600951385785,
"sig": "xxxxx",
"sigAlgorithm": "secp256k1",
"phloPrice": 1,
"phloLimit": 100000,
"validAfterBlockNumber": 341,
"cost": 100000,
"errored": true,
"systemDeployError": ""
}

Although the deploy is marked as errored=true, the node should provide better error info for the errored deploy.

Impact

Dependencies

Design

Need discussions.

Steps to implement the solution

Steps for integration testing

Resource estimation

[nzpr]

I think it is related, so mentioning here. @dckc reported that this deploy https://gist.github.com/dckc/9e04e4604498eab72410a487b6d28b8d ends up with this error No value set for rho:rchain:REVAddress. This is a bug in the normalizer or on the path from it.

[JosephDenman]

All of the gas is consumed because that's the default behavior of RuntimeManager for error-throwing processes. The error that I get is:"No value set for 'rho:block:timestamp'. This is a bug in the normalizer or on the path from it". It occurs in the evaluator when New is evaluated. It's not really a bug because the expected behavior is that the program throws an error when it attempts to reference an undefined system process. As for deployInfo, I agree that the error message should be returned, but that's not limited to this particular error.