First design for OpenTelemtry

[youben11]

• We extend the EVMEnvironment with a method to get the EVM context using in Otel (returning nil means it's disabled)
• As ops are executed sequentially in the EVM, we create a span per op based on the fetched context from the EVM implementation
• The fetched context is considered the root context, and if a span was already created, then all spans created here will be child spans to that one

This is an initial design that doesn't have to make a lot of changes to the codebase, we can extend it later with more events that are needed for observability.

Note: This is a breaking change as it introduce a new method to the EVMEnvironment interface. We should update the docs to take this into account and explain how someone could use Otel with fhevm-go.

[david-zk]

Looks good, left comment about possible improvements in the future

[david-zk]

I'm the author of the initial switch statement (looked good idea at the time for me) and maybe in the future we can replace this with a map of small abstraction, like structs of all the fhevm functions which contain, say

type fhevmPrecompileMethod {
  name string
  implementation <function signature which implements current switch block>
}

And have a generated map of these for first 4 bytes of method signature

map[[]byte]fhevmPrecompileMethod

Then we could just do one lookup to the map, and do one trace using name of the method not to repeat ourselves.

Also, in future bwCompatBytes logic could be just moved inside implementation method, say fheAddRun.
This was needed before when we supported separate precompile smart contracts instead of one, we no longer need that now

[youben11]

Yes, this seems a nice refactor, I will do that just after we merge this (probably today)