feat(core): disableable extensions & ops

[AaronO]

Streamlines a common middleware pattern and provides foundations for avoiding variably sized v8::ExternalReferences & enabling fully monomorphic op callpaths

Op middleware has the final say on whether an op is enabled/disabled/overridden, otherwise the logic is:

op.enabled = extension.enabled && op.enabled;

Entire extensions can be enabled/disabled, individual ops can also toggled in the extension constructor.

Main semi-open question is if disabled ops should throw or just no-op by mapping to op_void_a?sync thus returning undefined (no-op-ing is our current behaviour so I'm going to stick with that)

[ry]

A small unit test in core would be appropriate, I think

[bartlomieju]

Main open question is if disabled ops should throw or just no-op by mapping to op_void_a?sync thus returning undefined

Throwing is less surprising than silently doing a noop

[littledivy]

LGTM

[bartlomieju]

So it looks like you want to silently no op for disabled ops. I don't like this, it's surprising in my opinion

[AaronO]

So it looks like you want to silently no op for disabled ops. I don't like this, it's surprising in my opinion

Disabling ops is already a thing on main and by convention that means remapping to op_void_sync/op_void_async

I'll consider throwing in a follow-up, users can implement throwing in user-land with middleware remapping, so I'm currently unconvinced it should be the default. This is all low-level-ish stuff and caveat emptor ...