feat(forge) Native assertion cheatcodes

[klkvr]

Motivation

Adds native assert* cheatcodes to Vm

Solution

[mattsse]

great draft!

one nit re error messages, I think we want real error types via thiserror, so we can test formatting etc

maybe an enum or several standalone error structs

enum AssertErr {
 ....
}

wdyt @DaniPopes

[Evalir]

good draft! looking good so far imo.

Wonder if we can ship improvements incrementally? so we can get the equivalent native cheats in, and then improve errors and diagnostics in followups

[DaniPopes]

Suggested change

	#[error("Assertion failed")]
	#[error("assertion failed")]

[DaniPopes]

I believe

Suggested change

	Ok(assert_true(self.condition).map_err(|_| "Assertion failed")?)
	assert_true(self.condition).map_err(|e| e.to_string().into())

[klkvr]

This kind of conflicts with your other suggestion to rename error message, by default error on assert is "Assertion failed", and in that case it would be "assertion failed"

which one should I do?

[DaniPopes]

I don't see how they conflict, and error messages should be lowercase

[mattsse]

this looks great!
This should speed up compilation and finally makes tests fail as soon as an assert fails.

one thing we need to decide is, do we want to include them in the Vm interface or mark them internal and switch out all the assert Code in forge-std so function assertEq just calls vm.assertEq?

wdyt @mds1 @DaniPopes @Evalir

[Evalir]

This looks awesome to me.

I think we should just take the bandaid off and include them in the vm interface.

[klkvr]

One thing to consider re compile times is that after this PR we will have enough native cheatcodes to drop DSTest dep, but we still would need StdAssertions for assertEqCall* cheats

[mds1]

Per @klkvr's comment, since users won't yet be able to find+replace all assertEq* calls due to StdAssertions, I would include them in the public Vm interface and have forge-std functions call the native cheats under the hood to avoid breaking changes.

Once we also have everything in StdAssertions upstreamed, then we can add a deprecating warnings log to the forge-std methods to start the breaking change process (or just do it all of at once like @Evalir said if v1 is coming soon)

[mattsse]

sgtm!

pending @DaniPopes

[DaniPopes]

I don't see how they conflict, and error messages should be lowercase