Problem:
```
executor_test.go:151:
Error Trace: executor_test.go:151
executor_test.go:147
nep11_test.go:232
Error: Expect "{"name":"HASHY 3HNCEX8D9J0p\u002BLxmr3uPhOhSW90="}" to match "{"name":"HASHY 3HNCEX8D9J0p+Lxmr3uPhOhSW90="}"
Test: TestNEP11_OwnerOf_BalanceOf_Transfer
```
Solution:
Same as preesnted in #2006.
Base58 does not preserve one-to-one byte correspondence with the
original data, so different combinations of the same number of bytes
might have different encoded string length. We use GAS transfer to mint
HASHY token, where the token hash is Base58Encode(Ripemd160(data + txHash)).
The problem is that `invokescript` RPC call is used to define transfer tx
sysfee, thus, txHash during testinvoke differs from the actual one, that's
why resulting token ID may have different length during testinvoke and
real invoke. As far as we use token ID as a key to store contract
values, the storage price may also differ. The result is failing
TestNEP11_OwnerOf_BalanceOf_Transfer test due to `gas limit exceeded`
error:
```
logger.go:130: 2021-06-10T21:09:08.984+0300 WARN contract invocation failed {"tx": "45a0220b19725eaa0a4d01fa7a6cdaac8498592e8f3b43bdde27aae7d9ecf635", "block": 5, "error": "error encountered at instruction 36 (SYSCALL): error during call from native: error encountered at instruction 22 (SYSCALL): failed to invoke syscall 1736177434: gas limit exceeded"}
executor_test.go:219:
Error Trace: executor_test.go:219
nep11_test.go:132
nep11_test.go:235
Error: Not equal:
expected: 0x2
actual : 0x4
Test: TestNEP11_OwnerOf_BalanceOf_Transfer
```
Fixed by using base64 instead of base58 (base64 preserves the resulting
encoded string length for the same input length).
Update neofs-api-go to `v1.27.1`.
Add `WithURIAddress` client option.
Stop using `V2` abstractions outside
of the `api-go` library.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
This commit fixes the following Go vs C# state diff:
block 74613: value mismatch for key EwAAAHN0cmVhbXMvDg==: eyJpZCI6MTQsInN0YXJ0IjoxNjIyNTAwMjAwMDAwLCJzdG9wIjoxNjIyNTAyMDAwMDAwLCJkZXBvc2l0IjoxMDAwMDAwMDAsInJlbWFpbmluZyI6MTAwMDAwMDAwLCJzZW5kZXIiOiJmeEY4RDl2ZFU3K0gwcDV3NTlyWllMNytNSlE9IiwicmVjaXBpZW50IjoiSVV6c3pveFV0S1NGVnlZRGczSmdTQTFlbTFNPSJ9 vs eyJpZCI6MTQsInN0YXJ0IjoxNjIyNTAwMjAwMDAwLCJzdG9wIjoxNjIyNTAyMDAwMDAwLCJkZXBvc2l0IjoxMDAwMDAwMDAsInJlbWFpbmluZyI6MTAwMDAwMDAwLCJzZW5kZXIiOiJmeEY4RDl2ZFU3XHUwMDJCSDBwNXc1OXJaWUw3XHUwMDJCTUpRPSIsInJlY2lwaWVudCI6IklVenN6b3hVdEtTRlZ5WURnM0pnU0ExZW0xTT0ifQ==
I.e.:
```
{"id":14,"start":1622500200000,"stop":1622502000000,"deposit":100000000,"remaining":100000000,"sender":"fxF8D9vdU7+H0p5w59rZYL7+MJQ=","recipient":"IUzszoxUtKSFVyYDg3JgSA1em1M="}
```
vs
```
{"id":14,"start":1622500200000,"stop":1622502000000,"deposit":100000000,"remaining":100000000,"sender":"fxF8D9vdU7\u002BH0p5w59rZYL7\u002BMJQ=","recipient":"IUzszoxUtKSFVyYDg3JgSA1em1M="}
```
This is not a problem in practice, as all keys are prefixed
by a contract ID. However in theory it can lead to a different
state root after new portion of changes thus this fix.
This has the drawback of traversing expression each time the argument is
used. However this is not the case in our syscall/native wrappers.
The old behaviour can be restored by explicit local assignment.
