Fix TestsManifestGeneration tests

[sywhang]

Fix #46518

These tests sometimes fail because the call to disable the provider or roll over the file happens almost instantly after TraceEventSession.Flush(), and the Manifest data may not have been fully written to the file before we check for its existence. This adds a sleep between flushing and disabling the provider so that there's plenty of leeway for the payload to be fully written to the trace file.

[ghost]

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix #46518

These tests sometimes fail because the call to disable the provider or roll over the file happens almost instantly after TraceEventSession.Flush(), and the Manifest data may not have been fully written to the file before we check for its existence. This adds a sleep between flushing and disabling the provider so that there's plenty of leeway for the payload to be fully written to the trace file.

Author:	sywhang
Assignees:	-
Labels:	area-System.Diagnostics.Tracing
Milestone:	-

[josalem]

I don't like adding sleeps in tests, but that seems to be the pattern for this test already and as you've pointed out, we need to wait here anyway. Can you decorate the sleep calls you're adding with comments for why they are "necessary"?

[danmoseley]

Coming to this late, but could you not use the pattern of using a nominal (or no) sleep, doing the test, and if it fails, doing the longer sleep and testing again? This is the pattern we use many other places. Per the test history, we know that in the 99% case this sleep is not necessary. With the change as is, the tests all take longer to run, it's not a situation we want to be in.

[sywhang]

@danmosemsft thanks for the suggestion. So these sleeps were removed in a subsequent PR that addressed more issues on the test... But yes, I agree and I think we need to come up with a better synchronization mechanisms for the tracing tests as many of them are timing sensitive.