Add JsonRef

[jdtzmn]

This PR adds the upcoming AVM 7 json_ref opcode.

[barnjamin]

I like how you had the base64 .std/.url, does it make sense to do something similar here?

[jdtzmn]

It very well might. I could easily be convinced. My thinking is that if I saw the following:

JsonRef.string(Bytes('{"a":"b"}'), Bytes("a"))

I wouldn't be sure what the .string property meant at first glance. Without a thorough understanding of the json_ref opcode I wouldn't immediately understand whether string refers to the key type, or the input type, or the value's decoded type.

My hope was that explicitly having to set the format would make it clearer at first glance.

JsonRef(JsonRef.json_string, Bytes('{"a":"b"}'), Bytes("a"))

However, as I'm writing this, I'm thinking that named functions .as_string, .as_uint64, and .as_object would solve both issues. I'll add those 👍

[jdtzmn]

@barnjamin I'm having second thoughts about this. As I work more with the PyTeal library, it seems that the "PyTeal way" of doing things is to use dot notation for accessing properties but passed parameters for encodings or specifying return value types. For example, you see AssetParam.total() to access a property of an asset param, but EcdsaVerify(EcdsaCurve.Secp256k1, *args) for ecdsa verification.

I actually think using dot notation for everything could provide a better developer experience and I would probably be in favor of adopting that method moving forward. However, if we were trying to stay consistent with existing behavior, we should get rid of .std/.url/.as_string/etc in favor of exported enums as function parameters.

[michaeldiamant]

My lightly held 2c: I'm on-board with the PR's approach. If another reviewer has a strong opinion otherwise, I can be convinced to revert for consistency.

[michaeldiamant]

@jdtzmn Appreciate the effort here - Leaving approval under the assumption that threads I opened are resolved prior to merging.