Add poll_latest and sample_range scripts

[njgheorghita]

What was wrong?

Added two scripts to help with quick & easy network testing. These are meant to be "backups" to glados, but also will be very useful for running tests on kurtosis.

Later, I'd like to implement support for providers other than infura, but given that audit_latest requires a ws connection, which is really only "easily" available via infura (eg. pandaops doesn't support this), then I figured pandaops / generic provider support can wait

How was it fixed?

• audit_latest script, which will basically poll how soon "latest" data appears on the network
• sample_range script, which samples X number of randomly selected blocks from any given range

To-Do

• Clean up commit history and use conventional commits.

[KolbyML]

[ogenev]

I don't like coupling script dependencies with trin dependencies in main Cargo.toml.
It is also expected to add more scripts in the future (purging db and etc).

Having a bin directory inside src is also confusing and it is not very clear which file is the trin binary and which one is script without looking into Cargo.toml and the files.

I think a better strategy is to rename the src folder to bin and then add trin crate inside bin, for example see reth: https://github.com/paradigmxyz/reth/tree/main/bin/reth

This will require updating Cargo.toml and adding the trin crate as a workspace member.

Тhen we can add any rust script as a separate crate inside bin/. This way, Trin and any script will have separate Cargo.toml and dependencies.

[ogenev]

purge_db was removed:

Suggested change

	COPY --from=builder /trin/target/release/purge_db /usr/bin/
	COPY --from=builder /trin/target/release/poll_latest /usr/bin/

[njgheorghita]

@ogenev

I don't like coupling script dependencies with trin dependencies in main Cargo.toml.
It is also expected to add more scripts in the future (purging db and etc).

Agreed & agreed

Having a bin directory inside src is also confusing

That is the structure that is officially recommended. It's also the structure we were using when we had the purge_db.rs script.

It is not very clear which file is the trin binary and which one is script

I don't really agree. main.rs is pretty obviously the trin binary, as defined by the cargo standards.

Looking at reth, reth/bin/reth is a fairly large project, a separate workspace, with many contents. If our main trin process was a large project, then I would be inclined to follow the Reth convention. In our case src/trin.rs is basically just a simple script. Based on this, I'm not convinced that it's a convention worth adopting, when our use case seems to follow the standard use case defined in the cargo standards more closely.

Basically, I do agree it's not great coupling script dependencies with trin dependencies, but it appears to me like we're following cargo best practices. Seems like this is still a bit of an unsolved issue with cargo?

[njgheorghita]

@ogenev looks like there's a newly failing test in light-client ... not sure what the cause might be, but i'm getting the same failure locally problem was fixed in #1099

[ogenev]

⛵

[ogenev]

nitpick:

Suggested change

	(self.average_time * (self.success_count - 1) + new_time) / self.success_count
	(self.average_time * self.success_count + new_time) / (self.success_count + 1)