`AspNetResponseStatus` fails to trigger after API trace with the default profile

[kkeirstead]

Description

After collecting a trace via the API (with the default profile), my collection rule trigger (AspNetResponseStatus) will no longer trigger.

Repro Steps:

• Successfully trigger an AspNetResponseStatus trigger that looks for status codes in the 4xx range -> collects a GCDump
• Collect a trace via the API (e.g. /trace?name=FirstWebApp&durationSeconds=5)
• Attempt to trigger the AspNetResponseStatus trigger again -> fails to trigger

Configuration

This behavior was seen in the main development branch, as well as the current shipping version of the product (6.2.2). Testing was done locally against a basic .NET6 web app.

Regression?

Other information

@wiktork and @jander-msft had some initial thoughts on this - I'll let them attach any ideas below. We did discover that setting the trace profile for the API to CPU or Metrics made the issue go away, which implied that the issue may have to do specifically with the Http profile, with the termination of Http API traces preventing AspNetResponseStatus triggers from firing. It also appears that the rule cannot be triggered during an Http trace, which means any customer who starts a long-running trace with the default profile would immediately have their collection rules stop firing.

After doing a bit more investigation, it appears that this also fails using AspNetRequestDuration, but AspNetRequestCount appeared to be unaffected. A simple EventCounter trigger using cpu-usage was also unaffected.