feat: Add snap_startTrace and snap_endTrace support to snaps-jest

[Mrtenz]

This adds support for snap_startTrace and snap_endTrace to snaps-jest, and a toTrace matcher to go with it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.28%. Comparing base (27c8e14) to head (6c856d8).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3547   +/-   ##
=======================================
  Coverage   98.27%   98.28%           
=======================================
  Files         415      417    +2     
  Lines       11717    11765   +48     
  Branches     1821     1827    +6     
=======================================
+ Hits        11515    11563   +48     
  Misses        202      202           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Mrtenz]

I had to add this because we clear the trackables state for every request. We could consider not clearing performance traces between requests as well.

[FrederikBolding]

Would it be a lot of work to keep pendingTraces between runs?

[FrederikBolding]

Unsure whether most usage would be during a single request tbh 🤔

[Mrtenz]

We explicitly clear it, so it would be easy to keep it. Just unsure about the expectations.

[FrederikBolding]

Do we have no existing state between requests?

[Mrtenz]

Right now all the notifications and trackables are cleared:

snaps/packages/snaps-simulation/src/request.ts

Lines 104 to 105 in f08611a

	store.dispatch(clearNotifications());
	store.dispatch(clearTrackables());

But Snap state isn't.

[FrederikBolding]

Hmm. Up to you whether you think it makes sense to persist it between runs, we can always easily change the behavior.

[FrederikBolding]

Do we need logic to handle multiple pending traces with the same name/id?

[Mrtenz]

Other than changing it to LIFO like Cursor suggested, I'm not sure what we should change. Unless you think new traces should override existing ones if the name/ID is the same? I have no idea how Sentry handles it, but generally I would expect that Snaps don't run multiple traces at the same time with the same name.

[FrederikBolding]

Do we need to match on both name and ID? Are we expecting that Snaps will pass both (our example does not)?

[Mrtenz]

The name is required, but ID is optional. For matching, just passing a name in both cases will work (since undefined === undefined), but if the ID in the end request is different it will fail.

[FrederikBolding]

Perhaps fair enough to expect the same parameters on both sides

[FrederikBolding]

But I think there is a chance we have to adjust this based on usage

[FrederikBolding]

Suggested change

	state.traces = [];
	state.traces = [];
	// We are not resetting `pendingTraces` to let them persist between requests.

[Mrtenz]

Not sure if this is necessary since it's documented in the test as well