feat: Bound Method Realm support

[jaekwon]

When a function is called, it's usually enough to get the pkgpath from where the function is declared, to find out whether we are switching to a new realm or not.

But when the function is a bound method, and the method and declared type are defined in a /p/ package, we need to look at the owning (persisting) pkgpath of the receiver, if any. When one is found, it uses that.

There are some edge cases to consider, I'm not sure if they are all fixed, but we will find out.
Here are some that are considered;

1. if the receiver is an unpersisted new object with method, declared in a p module, it has no realm until it becomes persisted.
2. nil receivers aren't objects, so even if it were stored in a realm, it would be stored by "reference" from a pointervalue which also is not an object, so there's no realm to consider even after persistence.
3. if the method from 1 makes any modifications to the /p/ package's block state, it should result in an error and the tx should fail.
4. if a /p/ declared thing with method gets stored in realm X, it should be possible for realm Y to call it, and have it modify realm X (e.g. say realm X attached a closure to the thing).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.75%. Comparing base (1169658) to head (a61ab41).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1257   +/-   ##
=======================================
  Coverage   54.74%   54.75%           
=======================================
  Files         592      592           
  Lines       79197    79145   -52     
=======================================
- Hits        43359    43333   -26     
+ Misses      32568    32547   -21     
+ Partials     3270     3265    -5     

Flag	Coverage Δ
contribs/gnodev	23.53% <ø> (ø)
contribs/gnofaucet	15.31% <ø> (+0.85%)	⬆️
contribs/gnokeykc	0.00% <ø> (ø)
contribs/gnomd	0.00% <ø> (ø)
gno.land	62.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[albttx]

Any update on this @jaekwon / @moul ?

[thehowl]

txtar created by albttx which illustrates the kind of behaviour that should be fixed by this PR (or any continuation of this work) -- place in gnovm/cmd/gno/testadata/gno_test/:

# Set up GNOROOT in the current directory.
mkdir $WORK/gnovm
symlink $WORK/gnovm/stdlibs -> $GNOROOT/gnovm/stdlibs
env GNOROOT=$WORK

gno test -verbose ./examples/gno.land/r/demo/realm2

stderr '=== RUN   TestDo'
stderr '--- PASS: TestDo.*'

stderr '=== RUN   file/realm2_filetest.gno'
stderr '--- PASS: file/realm2_filetest.*'

-- examples/gno.land/p/demo/counter/gno.mod --
module gno.land/p/demo/counter

-- examples/gno.land/p/demo/counter/counter.gno --
package counter

type Counter struct {
	n int
}

func (c *Counter) Inc() {
	c.n++
}

-- examples/gno.land/r/demo/realm1/realm1.gno --
package realm1

import "gno.land/p/demo/counter"

var c = counter.Counter{}

func GetCounter() *counter.Counter {
	return &c
}

-- examples/gno.land/r/demo/realm2/realm2.gno --
package realm2

import (
	"gno.land/r/demo/realm1"
)

func Do() {
	realm1.GetCounter().Inc()
}

-- examples/gno.land/r/demo/realm2/realm2_filetest.gno --
// PKGPATH: gno.land/r/tests
package tests

import "gno.land/r/demo/realm2"

func main() {
	realm2.Do()
	println("OK")
}

// Output:
// OK

-- examples/gno.land/r/demo/realm2/realm2_test.gno --
package realm2

import "testing"

func TestDo(t *testing.T) {
	Do()
}