Fix most issues related to dependency update, except hashbrown version

[Nicceboy]

Fixes most of the issues related to dependency updates.
Could it be possible to do large changes in branch so that main does not end up into bad state?

hashbrown dependency update seems to break encoding of BitString type in BER for some standard tests, I don't know why yet. Should we downgrade that for now?

E.g. cargo test -p rasn-cms --test test_cms test_cms_signed 1> error.log

shows failures on BitString types only.

error.log

[Nicceboy]

I think the issue is related to the change of the default hashing algorithm of hashbrown and custom SET OF hash function does not work as expected.

[XAMPPRocky]

hashbrown dependency update seems to break encoding of BitString type in BER for some standard tests, I don't know why yet. Should we downgrade that for now?

We can downgrade for now, but let's make an issue for this as I don't want us to be restricted in what hashing algorithm we use, anything that depends on that should be changed or removed.

[Nicceboy]

hashbrown dependency update seems to break encoding of BitString type in BER for some standard tests, I don't know why yet. Should we downgrade that for now?

We can downgrade for now, but let's make an issue for this as I don't want us to be restricted in what hashing algorithm we use, anything that depends on that should be changed or removed.

The issue seems to be that new hashing algorithm is not deterministic anymore. Is deterministic too strict requirement? Only SET OF type would require that for equality checks. I don't know how we could do the type otherwise. Another option might be to use some shared hasher instance for both source and target in equality checks but I don't know if it will introduce other issues.

[XAMPPRocky]

Only SET OF type would require that for equality checks. I don't know how we could do the type otherwise.

I'm not sure what you mean, why would it be required? A regular Vec or HashSet don't rely on the hashes being equal for PartialEq implementations.

[Nicceboy]

Only SET OF type would require that for equality checks. I don't know how we could do the type otherwise.

I'm not sure what you mean, why would it be required? A regular Vec or HashSet don't rely on the hashes being equal for PartialEq implementations.

SetOf was a special type since the order of the elements should never matter. For that to be true, equality check nor hash should not depend on the order. Since the type cannot have Ord or PartialOrd requirement for elements, we need to rely on hashes on equality check. If hashing alrogithm includes randomness, the check will fail.

[XAMPPRocky]

SetOf was a special type since the order of the elements should never matter. For that to be true, equality check nor hash should not depend on the order. Since the type cannot have Ord or PartialOrd requirement for elements, we need to rely on hashes on equality check. If hashing alrogithm includes randomness, the check will fail.

I'm still not sure how that isn't solved by the following:

impl<T, S> PartialEq for HashSet<T, S>
where
    T: Eq + Hash,
    S: BuildHasher,
{
    fn eq(&self, other: &HashSet<T, S>) -> bool {
        if self.len() != other.len() {
            return false;
        }

        self.iter().all(|key| other.contains(key))
    }
}

[Nicceboy]

SetOf was a special type since the order of the elements should never matter. For that to be true, equality check nor hash should not depend on the order. Since the type cannot have Ord or PartialOrd requirement for elements, we need to rely on hashes on equality check. If hashing alrogithm includes randomness, the check will fail.

I'm still not sure how that isn't solved by the following:

impl<T, S> PartialEq for HashSet<T, S>
where
    T: Eq + Hash,
    S: BuildHasher,
{
    fn eq(&self, other: &HashSet<T, S>) -> bool {
        if self.len() != other.len() {
            return false;
        }

        self.iter().all(|key| other.contains(key))
    }
}

It doesn't note the variance between duplicate items.. but if we add that maybe it could work.

[Nicceboy]

Actually, the issue remains as the key is a hash value and if the algorithm is not deterministic, key might not be in the other object.