API changes to Ops

[ry]

ops.rs has grown to over 2000 lines and needs to be broken up.

We additionally have seen performance problems for very hot ops like read/write with flatbuffers. This has necessitated the ability to handle non-flatbuffer message (see dispatch_minimal.ts). We want to allow ops to use their own serialization - flatbuffers, JSON, serde, or just a custom message format.

We want the ability to dynamically load (dlopen) ops that are not included in the deno executable. See preliminary work in #2385.

Thus I want to do the following changes:

• refactor: split ops.rs #2753 Breaking up cli/ops.rs into cli/ops/read_write.rs, cli/ops/subprocess.rs, cli/ops/fetch.rs, ...

• Create a new OpDispatcher trait which has a name in addition to a dispatch function. This allows us to create subtraits like FlatBufferOpDispatcher which would allow simplify a lot of the parsing/serialization code. Example code.

• Add a new method to register op dispatchers dynamically. This would be called even for built-in ops at startup. isolate.register_op(op_read) feat: Use Isolate.register_op in CLI, take 2 #3039 (and others)

• Add op_id throughout op API #2734 Add a new integer parameter to Deno.core.dispatch() to specify which op is being called.

let readId: number = null;
function read(fd: number, buf: Uint8Array): number {
  if (!readId) {
    readId = Deno.core.ops["read"]; // lazy lookup
  }
  /* ... */ 
  Deno.core.dispatch(readId, cntrolbuf, zerobuf);
  /* ... */
}

Note the new Deno.core.ops which allows us to retrieve an op id from a string. (We're worried that passing the string directly to Deno.core.dispatch would be slow)

[bartlomieju]

1. Breaking up cli/ops.rs into cli/ops/read_write.rs, cli/ops/subprocess.rs, cli/ops/fetch.rs, ...

I'll be working on this

[ry]

I consider this closed in #3039. I'm sure there are other op changes, but at least we can dynamically import ops now using Isolate::register_op