Update registry.rs

[ziaptos]

Reverting the condition to check whether the bench tests failures persists.

Description

If before Entry::drop() calls Registry::maybe_remove, the weak ref under the same key1 and key2 is replaced, Entry::drop can be called recursively resulting in a deadlock. The crux is we try to see if the entry has been replaced by trying to upgrading it to a strong ref, and it possible that the upgrade is successful and the result becomes a only ref to the new entry.

This tries to fix it by determining the same thing by seeing if Weak::strong_count() is 0 instead of upgrading the weak ref.

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Other (specify)

How Has This Been Tested?

Key Areas to Review

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

[trunk-io]

⏱️ 16m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
rust-move-tests	10m	🟩
check-dynamic-deps	2m	🟩
rust-cargo-deny	2m	🟩
general-lints	2m	🟩
semgrep/ci	17s	🟩
file_change_determinator	13s	🟩
file_change_determinator	11s	🟩
permission-check	3s	🟩
permission-check	2s	🟩
permission-check	2s	🟩
permission-check	2s	🟩

🚨 1 job on the last run was significantly faster/slower than expected

Job	Duration	vs 7d avg	Delta
check-dynamic-deps	2m	1m

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}