Add more conflict types to ConflictFinder

[grasphoper]

📝 Summary

Add more conflict types to ConflictFinder as per #226

A brief overview of the changes:

• I added multiple new mapping entries to ConflictFinder, namely

    group_balance_reads: HashMap<Address, Vec<usize>>,
    group_balance_writes: HashMap<Address, Vec<usize>>,
    group_contract_creations: HashMap<Address, Vec<usize>>,
    group_contract_destructions: HashMap<Address, Vec<usize>>,

• Added conflicts that can be related to those fields
• Added combine_groups - a utility fn to reuse code
• Added ConflictFinder.add_group_to_index and ConflictFinder.remove_group_from_index to reuse code and improve readability; index here means search index, or different member mappings of ConflictFinder

---

✅ I have completed the following steps:

• Run make lint
• Run make test
• Added tests (if applicable)

[grasphoper]

For anyone reviewing, please take a look at TODO comments I left and let me know what you think!

[ZanCorDX]

The original code had some copy/paste (our bad!) but you may avoid it.
Example:
on remove_group_from_index you can create a fn like:

    fn remove_group_from_map<K: std::cmp::Eq + std::hash::Hash + Clone>(
        group_id: usize,
        key_to_group: &mut HashMap<K, Vec<usize>>,
        keys: &Vec<K>,
    ) {
        for key in keys {
            let groups = key_to_group.entry(key.clone()).or_default();
            if let Some(idx) = groups.iter().position(|el| *el == group_id) {
                groups.swap_remove(idx);
            }
        }
    }

And just call it 6 times.
The same goes for add (maybe somewhere else?).

[ZanCorDX]

About the TODO ideas:
1- We could change HashMap to BTreeMap ensuring that SlotKey's ordering compares Address first. Posible con: BTreeMap could be expensive.
2- Use nested HashMaps. The first level for address and the second level for key.
This way we don't get redundant structures.

[grasphoper]

@ZanCorDX thank you for all your suggestions. I implemented them and just pushed updated code! Went with a 2-layer HashMap as the "address conflict checking" solution.

[grasphoper]

Hi @ZanCorDX . Any more changes you would want to this?

[github-actions]

Benchmark results for c01fc23

Report: https://flashbots-rbuilder-ci-stats.s3.us-east-2.amazonaws.com/benchmark/c01fc23-17776cc/report/index.html

Date (UTC)	2024-12-12T21:12:28+00:00
Commit	c01fc235ec873583bdde1d5d1a58d5ff34ad4300
Base SHA	17776ccfde349baed05b523883493c890918aac1

Significant changes

Benchmark	Mean	Status
MEV-Boost SubmitBlock serialization/JSON encoding	61.93%	Performance has degraded.

[wjmelements]

It is hard to review code that is force-pushed. Every force-push, the entire changeset must be reviewed again.

[grasphoper]

Hi @wjmelements sorry about the force-push. I was rebasing this branch to the latest changes from upstream/develop, but git saw them as unique new changes, so I forcepush-removed all the commits from upstream. No changes made to this PR

In the force-push, it shows that the force-push was to 7def2e9 this commit, which was the one you last reviewed. Does this help?

[grasphoper]

@wjmelements

I've not worked with cross-repo PRs like this before. Any advice on how I can rebase onto the upstream/develop cleanly?

[wjmelements]

nice

[ZanCorDX]

Can you fix the lint errors so we can merge?

[grasphoper]

@ZanCorDX I've looked at those and not sure how to proceed. They're lint errors from other pieces of code, not touched by my changes. Is it a common thing to happen?

I can fix them in this PR, but seems like a weird issue. LMK if I should just proceed to fixing them

[grasphoper]

@ZanCorDX Actually the linting errors were produced only by the newer rust toolchain and after updating it and merging new commits from upstream, the lint warnings seem to have disappeared. Could you rerun the workflows again to see if all is good now?