chore: rewrite trin-bridge simulator increasing test accuracy + test automation

[KolbyML]

This PR is now ready to review

#110 (comment)
#110 (comment)
#110 (comment)
Why this PR was made can be read in the comments linked to above.

This PR will in short more accurately test trin-bridge by testing the docker build of the latest bridge release, instead of using the bridge as a library.

In theory we can now create a mock pandaops and do backfill tests and latest tests now if we wanted to, but this is the start to make this all possible.

Important note
To run this simulator you will have to include trin-bridge as a client example?
./hive --sim trin-bridge --client trin,trin-bridge

If you forget to add this the simulator will panic asking for you to add this. Because of how hive was designed this is required. In the future we can probably remove this requirement, but it is not priority and it should be done after we transition from ethereum/portal-hive -> ethereum/hive. Since this will be a change modify the hive code itself so I want it reviewed by them whenever that time comes.

[KolbyML]

This PR is now unblocked and ready to review

[carver]

Important note
To run this simulator you will have to include trin-bridge as a client example?
./hive --sim trin-bridge --client trin,trin-bridge

I'm glad you mentioned this. Can you also open a PR against the ansible configs to reduce breakage here? Might need to talk to Paul to make sure those new configs are deployed (I've never handled portal-hive deploys) cc flamingo @ogenev

I think this is an example of a line that has to change, but you better confirm with Paul:
https://github.com/ethereum/cluster/blob/6cc5dae95b1cc826314cf5b4af61fb12a38cb699/portal-hive/ansible/roles/hive/templates/hive-cron.sh.j2#L51

[carver]

This is mostly a rubber-stamp. I scanned it, and it generally looks good to me! 👍🏻

I'm assuming you tried it out locally. Just be sure to coordinate with Paul so that portal-hive doesn't break, because of the new CLI arg requirement.

[njgheorghita]

[njgheorghita]

We already have these constants over inside portal-interop/src/constants.rs, is there any way we can import those? If not, I'd recommend moving these to a single location where they can be imported wherever they're needed in the codebase rather than copying the constants multiple times

[njgheorghita]

Or this one?

[KolbyML]

Going to handle it in a follow up PR. Currently there is no good one place to put this.

So I am thinking of hosting a crate on ethereum/portal-spec-tests with test utils crate. A issue with this is then we have to update that repo to use new utils in this repo. So it would only be used for non-simulator-specific constants, and be updated less frequently to eventually deduplicate constants.

We have hivesim-rust, but I wouldn't put these constants there as these are not related and contamination is bad.

And there isn't really a good place to declare a crate in this repo for common utils expessially with our goals of being re-included into ethereum/hive, breaking the projects structure would be a no no.

This request didn't really feel like a blocker to merge because of the reasons above more of a nit-pick which doesn't have the highest priority. Well yes it is nice to have no duplication of common constants between simulators, this PR isn't the place to change that. And these simulators have been rewritten almost 3 times now in how we structure tests, so where we put constants is the last of my worries.

I was planning to do a follow up PR relatively soon after I incorporated using ethereum/portal-spec-tests repo, to which would have answered this question. Didn't expect such a quick turnaround xD

[njgheorghita]

Sounds good, in the future it's worth mentioning how you're going to resolve a comment before hitting the resolve button, otherwise to the other person it looks like you just ignored it. Also, it gives a chance for the other person to have input into the planned resolution.

[KolbyML]

Sounds good 👍