Improve CalculateNetworkFee for contract signers

[roman-khimov]

Summary or problem description
CalculateNetworkFee as it is now executes verify methods for contract-based witnesses, but it can lead to wrong results if verify has parameters that can't be provided at this stage (like a transaction signature). Such methods will just fail leading to inability to use CalculateNetworkFee for what it's intended to do. Technically it's still the same issue as #840 (reminding of #1763 (comment) as well), but while it can't be solved for the generic case we can make some improvements for deployed contracts specifically.

Do you have any solution you want to propose?

1. Ignore verify execution results. We're calculating fees here, so witnesses can fail (take standard signature contracts for example, they're not even executed, we know they'll fail) and it's OK. But we'll still have some (maybe not perfect, but still) data for the GAS amount needed for execution (and contracts can use Runtime.BurnGas to compensate for any differences with the happy path).
2. If no invocation script is provided, try to determine its size from the parameters (and even create some stub for it). It can't be perfect also, but NEP-14 is helpful in many cases, we know the size of Boolean, Hash160, Hash256, PublicKey and Signature quite well. Integer is quite predictable in its upper limit too. Other types not so much, but I'd expect them to be used a little less often than hashes or signatures.

This won't solve all problems, but I think this way we'll cover a bit more cases which can be helpful for dApps.

Neo Version

• Neo 3

Where in the software does this update applies to?

• RPC
• Wallet

[roman-khimov]

Even more provocative, we can improve this a bit:

neo/src/Neo/Wallets/Wallet.cs

Lines 658 to 661 in 5f4c14e

	else
	{
	//We can support more contract types in the future.
	}

by executing whatever is given in the invocation/verification scripts. Of course this will fail as well, but in many cases the GAS spent will be correct and if there is a stub invocation script provided by the user then the size can be calculated correctly.

Again, not perfect, but something that will cover a bit more use cases.

[roman-khimov]

Implemented in NeoGo 0.99.3.

[roman-khimov]

See https://github.com/nspcc-dev/neo-go/blob/d9d9d00775570f8ce6b6a1524bfe9db44fb8407b/pkg/services/rpcsrv/server.go#L959-L1000, https://github.com/nspcc-dev/neo-go/blob/d9d9d00775570f8ce6b6a1524bfe9db44fb8407b/pkg/services/rpcsrv/server_test.go#L3142-L3288 and https://github.com/nspcc-dev/neo-go/blob/d9d9d00775570f8ce6b6a1524bfe9db44fb8407b/pkg/services/rpcsrv/client_test.go#L541-L855.