feat(tests): extend Op with Op.OOG macro opcode

[winsvega]

🗒️ Description

I think it would be handy to have test purpose Op that will trigger OOG if called
This will simplify parametrisations and code in tests when paramtrising over subcall return types
Such as RETURN, REVERT

Op.OOG(x, y) is replaced with Op..SHA3(0, 100000000000)
alowing to use

@pytest.mark.parametrize("call_return", [Op.RETURN, Op.REVERT, Op.OOG])
...
contract_code = Op.MSTORE(0, Op.TLOAD(0)) + call_return(0, 32)

Example:
#440

🔗 Related Issues

#455

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[marioevz]

I really like the idea! Just a couple of suggestions so let me know if it sounds ok to you and if it still achieves the original purpose you were thinking of.

[winsvega]

what about this part?

+    def __eq__(self, other):
+        """
+        Required to differentiate between SELFDESTRUCT and SENDALL type of cases
+        """
+        if not isinstance(other, Opcode):
+            return NotImplemented
+        return self._name_ == other._name_

I see that if you use SENDALL it will still be trated as SELFDESTRUCT
not an issue, but if you assign something in the constructor of SENDALL opcode in enum list
it won't have an effect, because it falls back to SELFDESTRUCT constructor

ah this part is actually required if Macro commands live in the same enum because they are based on the same opcode
it should know that those are different objects

[marioevz]

Still not completely on-board with the idea that the opcodes and the macros should live in the same Enum, but definitely open to discuss it!

What do you guys think? @spencer-tb @danceratopz

[marioevz]

Some small comments.

[danceratopz]

I really like this, but I'd rather see Macro defined as its own, independent type.

[winsvega]

Why Macro can't be inherited from Opcode?

I mean, then I will have to implement () logic for it that returns bytes.

[danceratopz]

Looks good to me! I like the new separation between Macro and Opcode.

@winsvega Could you just check the suggested docstring change before we merge?

[danceratopz]

The suggested change has nothing to do with the addition of the Macro class, but came up whilst reviewing #440,