difftest-core: setup refactorings

[danwt]

Some pure refactorings for the current diff testing setup. This PR is a first batch of improvements but more are coming.

This PR does't change any semantics.

[danwt]

@smarshall-spitzbart here's another one that can use

• Adds Cryptographic Identity utility for working with various keys ect #470

[shaspitz]

The changes later on in the PR are great and only relevant to diff tests.

I have concerns with a lot of the helpers at the top of tests/difference/core/driver/setup.go. Lots of parallel code that could be implemented differently to build upon existing abstractions from the ibctesting package, or E2e test abstractions.

I do think the efforts are useful! I just think we may as well consolidate code, and bridge the gap between e2e <-> diff tests when focusing on refactors.

We can def meet and talk about more specific/granular ways to consolidate helpers

[danwt]

Hey I appreciate the comments but the big picture is missing. These are quick refactors to make this thing more readable in the short term so that it can be ripped out and replaced.

Consolidating with e2e efforts is still a few steps down the road.

The eventual goal is to have something that lets us get away from ibctesting and all the associated problems by letting you

• arbitrarily progress in block height and time in one chain and not others
• precisely control packet delivery without also progressing in block height and time
• precisely control ack delivery ...
• precisely control client updates (and by extension client expiry)
• precisely control packet timeout (or lackof)
• for an abitrary network topology

The purpose of this PR is to make things more workable for me in the short term, and to get that into main so that future changes have smaller PRs too. It's not the be all and end all.

[shaspitz]

Hey I appreciate the comments but the big picture is missing. These are quick refactors to make this thing more readable in the short term so that it can be ripped out and replaced.

Consolidating with e2e efforts is still a few steps down the road.

The eventual goal is to have something that lets us get away from ibctesting and all the associated problems by letting you

arbitrarily progress in block height and time in one chain and not others
precisely control packet delivery without also progressing in block height and time
precisely control ack delivery ...
precisely control client updates (and by extension client expiry)
precisely control packet timeout (or lackof)
for an abitrary network topology
The purpose of this PR is to make things more workable for me in the short term, and to get that into main so that future changes have smaller PRs too. It's not the be all and end all.

The later code in the setup file looks great, I have issues with the code up top because:

• parallel test helpers just add onto the code that we'll need to delete later during consolidation, and is therefore additional tech debt
• It requires additional review time to approve of this temporary code, we have almost 20 open PRs already
• It requires new context and understanding to use parallel helpers instead of widely used global helpers

I don't think that consolidating code goes against any of the goals you've outlined. Even if the ibc testing package is flawed, we should reuse any code from that package that is already useful and familiar, and simply not use the bad code. I'll also add that not everything I'm mentioning has to do with the ibc testing package.

[shaspitz]

Consolidating with e2e efforts is still a few steps down the road.

Imo (and especially with refactoring PRs) our attitude should always be one of collaboration, making that an afterthought leads to tech debt

[danwt]

Ok it's probably not worth this making its way onto main. You rightly point out its not worth taking up the time for people to review for temporary code.