fix hacky registration of MiMC

[Tabaie]

No description provided.

[ivokub]

Looks good - I would only change the the order of import to avoid import cycles in the future.

[Tabaie]

Seems like having mimc importing hash already creates a cycle.
Because BinaryHasher imports uints which ultimately imports mimc. Perhaps we should move BinaryHasher to another package?

[ivokub]

Seems like having mimc importing hash already creates a cycle. Because BinaryHasher imports uints which ultimately imports mimc. Perhaps we should move BinaryHasher to another package?

I'll check the import cycle. Maybe indeed having the BinaryHasher inside std/hash is not optimal, but I'll see maybe there is a way which still would allow keeping it there.

[ivokub]

@Tabaie - so I tried a few options and imo this looks the best. Imo having the constructor which returns the direct type MiMC is historic, so I kept it for backwards compatibility, but for new usages I think the mimc.New would be better anyway, as it concretely describes the interface we implement.

Another option would have to move BinaryHasher interface out from std/hash, but I have seen people already using it and I'd rather not break stuff. I think the option right now is a good balance between allowing to use MiMC internally whenever we need without importing std/hash while keeping the backwards compatibility.

But - before I'm satisfied with the PR fully, I'd still want to make the hash constants more type safe than they are right now. Imo using strings could cause issues and better to use the approach from Go std lib and gnark-crypto where we have the hash functions registered by constants. I'll do it tomorrow.