feat: add separator to rpc `block_results` to identify msg & response pair

[r3v4s]

It kinda closes #2055 ( IN VERY UGLY WAY ) I'm opening this pr to get some ideas.

Currently, keeper does make response data with \n as separator to separate number of responses for single function. https://github.com/gnolang/gno/blob/80575054429e07c221f1453104dd0ad29e33291c/gno.land/pkg/sdk/vm/keeper.go#L307-L312

If single function returns 2 string, response may look like this

("1" string)
("2" string)

However as describe in #2055, response for single tx with multi-msg really doesn't separate response values.

So this pr adds \n\n as a separator for every function.

sample contract

package returns

func FuncNo() {}

func Func2() (string, uint64) {
	return "asd", 123
}

func Func3() (int64, string, uint64) {
	return -1, "hmm", 78978
}

call with multi-msg

await adena.DoContract({
  messages: [
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "FuncNo",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "Func2",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "FuncNo",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "Func3",
        "args": []
      }
    },
    {
      "type": "/vm.m_call",
      "value": {
        "caller": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "send": "",
        "pkg_path": "gno.land/r/r3v4/returns",
        "func": "FuncNo",
        "args": []
      }
    }
  ],
  gasFee: 1, 
  gasWanted: 2000000
});

block_results from rpc with b64 encoded

KCJhc2QiIHN0cmluZykKKDEyMyB1aW50NjQpKC0xIGludDY0KQooImhtbSIgc3RyaW5nKQooNzg5NzggdWludDY0KQ

b64 decoded

("asd" string)
(123 uint64)(-1 int64)
("hmm" string)
(78978 uint64)

two problem exists with above response

1. It needs to do something about function that doesn't return any value
2. It needs to divide results string for each function

in this pr response b64 encoded

CgooImFzZCIgc3RyaW5nKQooMTIzIHVpbnQ2NCkKCgoKKC0xIGludDY0KQooImhtbSIgc3RyaW5nKQooNzg5NzggdWludDY0KQoKCgo

decode b64 and divide by '\n\n'

From now, we know...

1. tx had 5 messages
2. first, third and fifth msg function doesn't return anything
3. second msg function return 2 values
4. fourth msg function return 3 values

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 54.19%. Comparing base (8057505) to head (054f323). Report is 17 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2063      +/-   ##
==========================================
- Coverage   54.96%   54.19%   -0.77%     
==========================================
  Files         481      520      +39     
  Lines       67391    73195    +5804     
==========================================
+ Hits        37040    39668    +2628     
- Misses      27330    30300    +2970     
- Partials     3021     3227     +206     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[r3v4s]

@zivkovicmilos @leohhhn As we talked this pr does change rpc block_results response to identify msg & result pair.

But it doesn't cover custom return type such as type Blake struct.

Perhaps we can keep this pr open for historical, and find some better ways to resolve issue.

[r3v4s]

I cannot agree with this is closing #2055 , but if we remove that trigger from this PR we can merge it as a small quality of life from people trying to know what is the output from a specific version.

Good point, just changed to related rather than closes