AFAICT this IIFE didn't accomplish anything as its result was immediately returned.

We can create the ActorContainer and even return an existing Actor without taking the isolate lock, as we aren't executing any JS code in the target isolate.

Since we have to make a copy of the ID anyway, capture the copy upfront.

Keeping a whole separate table for these, keyed on the same string, is a waste. It would be pretty bad if they got out-of-sync anyway.

Pure code move, no changes.

Turns out this is no longer used.

…ets.

I want to make sure I don't break this with subsequent changes.

In the next commit I'll be removing ActorContainerRef and just make ActorContainer itself refcounted. This lays some groundwork for that.

This seems more straightforward.

The body of `start()` is entirely moved code with no logic changes.

`getActor()` is the only public interface now.

…ime.

In the process, get rid of getActorImpl() and GetActorResult.

An RPC call on an already-broken stub should throw the brokenness reason, but instead it threw an "internal error" which was a "PromiseFulfiller not fulfilled" error under the hood.

I'm fixing that here because I need it fixed for a test I'm writing in a later commit.

In production, when an actor breaks, any stubs pointing at it are permanently broken. Using them again will repeatedly rethrow the broken reason.

In workerd, though, the stub would "repair itself", switching to a new DO on subsequent requests. This is incorrect!

This commit makes workerd match production.

This API wasn't acutally aborting the actors, it was just leaving them unreachable. With the recent changes, the existing stubs would continue pointing at the old instances of the objects, which still worked. But even before those changes, there would have been a problem if the actors were doing work in the background -- that work would keep running even after they were supposedly aborted, even as new instances could start up in parallel, leading to split brain.

In a Durable Object, the type of `ctx.id` is supposed to be of type `DurableObjectId`, and in production, it is.

Way way back in #605, a bug was introduced such that `ctx.id` became a string for Durable Objects in workerd. But `ctx.id` is only supposed to be a string for "ephemeral objects" (aka colo-local actors).

Somehow, nobody ever noticed? Probably because the only thing most people would do with it anyway is stringify it, which JavaScript is really good at doing automatically.

Anyway, this fixes the bug, restoring the proper type.

(Also this tidies up ownership of the key strings in the actor map. The key is now owned by the ActorContainer.)