Constructing a WorkerEntrypoint from userland

[penalosa]

This PR adds a sample that demonstrates that it's not possible to construct a WorkerEntrypoint in userland with a user-provided ctx object. Instead, this error appears:

workerd/server/server.c++:3880: error: Uncaught exception: workerd/jsg/_virtual_includes/iterator/workerd/jsg/value.h:1473: failed: remote.jsg.TypeError: Failed to construct 'WorkerEntrypoint': constructor parameter 1 is not of type 'ExecutionContext'.

This is important for the Vitest integration because we need to be able to (within a single "real" execution context):

• Construct a WorkerEntrypoint with a custom execution context
• wait for all waitUntils in the custom execution context to be settled
• Do some assertions

This works with default export-style workers, because the fetch() method can just be called directly with the custom execution context, but that's not possible with WorkerEntrypoint-style workers.

---

Or at least that was the case! Thanks to the changes now in this PR, the above is possible—and WorkerEntrypoint can be constructed with any object, allowing for custom execution contexts.

[kentonv]

I guess this is just because the constructor is declared to take ExecutionContext:

workerd/src/workerd/api/worker-rpc.h

Lines 493 to 500 in 1dfb447

	class WorkerEntrypoint: public jsg::Object {
	public:
	static jsg::Ref<WorkerEntrypoint> constructor(const v8::FunctionCallbackInfo<v8::Value>& args,
	jsg::Ref<ExecutionContext> ctx,
	jsg::JsObject env);
	JSG_RESOURCE_TYPE(WorkerEntrypoint) {}
	};

I think literally just changing the type of ctx from jsg::Ref<ExecutionContext> to jsg::JsObject would solve the problem, no other code changes.

[kentonv]

Can we convert the stample into a test, please?

Our samples are meant to be documentation. We should only have samples covering common use cases, to avoid overwhelming users with noise.

[kentonv]

Could add this to js-rpc-test pretty easily.

[danlapid]

@kentonv added test and cleaned up sample