Provide option to delete Deno namespace in worker

[kevinkassimo]

Add an option to Worker creation such that worker could be sandboxed (no access to window.Deno namespace)

The condition is propagated (e.g. if a sandboxed worker tries to create another worker, it will always also be sandboxed)

This is achieved by adding a condition to per worker/isolate State and calling denoMain() with param whether to preserve or delete window.Deno

(The locations where things are attached/bounded to Deno or Deno.core is growing more nebulous. Maybe we need better comments for it)

Tests needed. Will try to add them after first-round review (to ensure no leaking of the namespace through other channels) Added

[ry]

Seems reasonable. It’s a little annoying to lay all this pipe for just this one boolean. It makes me wonder if we should future proof this but having an options object of some sort... but I think it’s not much code so probably better to just add the boolean as you did.

I could imagine wanting to do something where you restrict permissions in the child worker - say limit network access...

[kevinkassimo]

I could imagine wanting to do something where you restrict permissions in the child worker - say limit network access...

Yeah sounds reasonable, though I do feel the sandboxing provided by this change is quite similar to the browser environment. Anyways we might experiment with that in another PR.

Also just added a basic integration test.

[ry]

nice test

[ry]

Could you add something to the manual or JSDOC describing this behavior?

[ry]

LGTM