Allow cloning the hash ring to use iterators effectively

[grcooper]

There was a case (that is outlined in the test) that did not work, due to not being able to clone.

The iterator worked fine for the cases where the HashRing is in a single context, but as soon as it is shared we cannot iterate through the entire list.

If you know a better way to get around this, please let me know, but this was the only solution that I could find.

[grcooper]

Deriving the clone trait seems fine to me, but I'm not sure I understand the motivation for doing so. Is it just to be able to duplicate the hash ring?

I couldn't for the life of me find a way to store the Hashring on a struct, and then iterate through that struct and do an operation using the objects inside. The only way you could iterate through the hashring was if you already had a mutable version that was not held within a struct.

It might have been possible using lifetimes, I'm just not yet enough of a rust expert to see the incantation needed.

The example I gave in test shows the use case.

    struct TestIterStruct {
        ring: HashRing<String>,
    }

    impl TestIterStruct {
        pub fn print_each(&self) -> Vec<String> {
            let mut v = Vec::new();
            for node in self.ring.clone().into_iter() {
                v.push(node);
            }
            v
        }
    }

The print_each method doesn't work because we don't have access to the node in the loop without doing a clone.

[timvisee]

For Qdrant we'd like to be able to clone the hashring too.

Our use case is dynamic resharding. We'd like to have two hashrings alongside each other during the resharding process. The second one would be modified to reach the desired state. It would be helpful if we could clone the existing one to achieve this.

@jeromefroe Would you see this as a valid reason for deriving or implementing Clone? I'd be very happy to work on any necessary changes in this PR as needed.

Edit: I attempted to revive this in https://github.com/jeromefroe/hashring-rs/pull/25.

[jeromefroe]

@timvisee thanks for looking into this! I'll close this PR in favor of your newer PR #25.