refactor(ops): allow 2 generic deserializable args

[AaronO]

Now that ZeroCopyBuf is natively supported in serde_v8 we no longer need to constrain ourselves to 1 structured arg and 1 buf arg, users are free to use their 2 args however they like.

Follow up to #10432

Notes

• Since the args are generic we can no longer meaningfully track metrics' bytesSentData (CC @lucacasonato)
• There's been debate about raising the op arity from 2 to 3, I'm keeping it at 2 for retro-compat, might consider 3 down the line after evaluating the number of ops that would benefit from it and whether they're in hot paths

[bartlomieju]

Does this PR mean that users can send two payload (JS objects) instead of payload + zero copy buffer?

[AaronO]

Does this PR mean that users can send two payload (JS objects) instead of payload + zero copy buffer?

Yes, or 2 ZeroCopyBuffers. Both opcall arguments can now contain "anything" deserializable, which includes structs/tuples/arrays/ZeroCopyBufs (ZeroCopyBufs can be nested in tuples/structs etc...)

[bartlomieju]

Does this PR mean that users can send two payload (JS objects) instead of payload + zero copy buffer?

Yes, or 2 ZeroCopyBuffers. Both opcall arguments can now contain "anything" deserializable, which includes structs/tuples/arrays/ZeroCopyBufs (ZeroCopyBufs can be nested in tuples/structs etc...)

Is there specific use case you have in mind for such approach? I'm worried it will lead to some ops using 2 JS objects as args without a good reason.

[piscisaureus]

LGTM