[BUG] - Duplicate actor names with remote enabled will cause DHT corruption.

[All8Up]

Bug Description

With the 'remote' feature enabled, duplicate actor names will corrupt the DHT.

Steps to Reproduce

let test_0 = kameo::spawn(Test::new());
test_0.register("test").await?;
// On the local or a remote peer:
let test_1 = kameo::spawn(Test::new());
test_1.register("test").await?; // <- Overwrites the actor/peer ID's and the first 'test' is hidden.

Expected Behavior

Kameo should dissallow the second register or store unique keys in the DHT such that the first actor is not simply 'forgotten'. With two peers involved, it is most likely that the last peer to join would overwrite the first actor causing a the swarm to fragment unintentionally where any new lookups will target the latest actor and ignore the first one. Unregister of the first peer will likely remove the key and cause future links to fail. Likely all the supervision and related items will be corrupted and "bad things will happen (TM)"....

Actual Behavior

The second call to register is simply changing the record data in the DHT to point to the second instance thus 'hiding' the first instance.

Environment

Not environment specific.

---

Discussion

The initial problem is deciding which solution to pursue. Either Kameo must enforce unique actor names or it must allow duplicates in a reasonable manner. If this were not specific to 'remote', refusing to allow duplicate actor names would be the proper solution. Unfortunately, with the addition of networking in a p2p environment, that is not a simple solution that can be easily done. Breaking things down further into benefit/detriments:

• Unique Actor Names
  • Benefits
    • Simple to implement in non-remote.
    • Simplified API remains in place, no patterned searches required.
    • Nothing fancy required.
  • Detriments
    • Will not work in 'remote' without:
      • Likely a solution much like what I was writing when I detected this issue, a leader/follower based transactional log for all names in the swarm.
      • Temporary link downtime between swarm portions would cause bifurcation and potential conflicts when the link comes back up. Conflict resolutions in such cases are extremely difficult.
• Duplicate Actor Names
  • Benefits
    • No duplication checks required. I.e. no transaction log required to validate names.
    • No bifurcation of the swarms and no merging of conflicts need be resolved. NOTE: only applies to Kameo, users have to deal with their own data problems in such cases.
    • Relatively simple and works with and without the 'remote' feature enabled.
  • Detriments
    • Impacts name lookup in both local and remote.
    • Keys stored for lookup must encode additional data which will require filtering during lookup.
      • Local would change to using a BTreeSet and performing a linear search between lower and upper bounds for the specifically named actor.
      • Investigating the kad module to see what is viable there. Everything seems to revolve around "https://docs.rs/libp2p/0.55.0/libp2p/kad/store/trait.RecordStore.html" and the provided iterators. Worst case, linear search through the iterator returned by 'provided' will function though it will end up as a scaling issue if someone decides they really need 1million actors...

This is currently just rehashing the initial thoughts in #129 in order to kick off any discussion points missed. Further investigation will likely have to wait while I get back to my real job. : )