Add remote actors to the name registry

[calebfletcher]

This PR registers remote actors into the node's local registry, and adds an integration test to demonstrate that this works.

[slawlor]

So I actually thought about this when writing all the remote actor logic (I should probably have written it down somewhere when I thought about it lol).

What are your thoughts on if there's already an actor with the same name registered?

I.e. Node A - has actor "test" running Node B - has actor "test" running

Node A then joins Node B, which trying to re-register the same name will fail. What are your thoughts on that?

[slawlor]

Right now, I think it'd fail to spawn the relevant RemoteActor instance, and might just swallow the error?

[calebfletcher]

So I actually thought about this when writing all the remote actor logic (I should probably have written it down somewhere when I thought about it lol).

What are your thoughts on if there's already an actor with the same name registered?

I.e. Node A - has actor "test" running Node B - has actor "test" running

Node A then joins Node B, which trying to re-register the same name will fail. What are your thoughts on that?

I've spent some time thinking about this, and I think there are a few different options going forward:

1. Register names with a first come first served strategy, ignoring subsequent requests to register the names. This is the closest aligned with the current behaviour, but has some sharp edges when actually trying to use it. It would make the whole name registry have a race condition, since if you connect to 2 different nodes which each have actors with the same name, then it would depend on which one completes authentication first which is not deterministic.
2. Allow more than one actor to be registered with a particular name (and change the where_is function to return a Vec). This would solve the issue and prevent conflicts, but would effectively turn the registry into a way to automatically register actors into process groups.
3. Split the registry based on which node the actors come from, changing the API to be something like where_is_by_node(name; ActorName, node: NodeId). Since ractor itself doesn't seem to know about the nodes in ractor_cluster, this would probably have to go into ractor_cluster. This would fundamentally change the philosophy of ractor/ractor_cluster (that it is completely transparent for most purposes whether an actor is on your own node vs a remotely connected node).

My personal opinion is that option 2 is the most flexible and reliable, but the significant overlap with process groups may mean that it may not be worth implementing.

[slawlor]

My personal opinion is that option 2 is the most flexible and reliable, but the significant overlap with process groups may mean that it may not be worth implementing.

This was essentially where I settled when I first wrote the functionality. However I believe Erlang does indeed support globally addressable actors, i.e. global in a full cluster like this. So it should theoretically be possible. Let me look into how they did it, and see if we can replicate that kind of functionality.