Add a filter for faults to avoid bucketing

[ryzngard]

Helps remove AssumeNotNull from the fault parameters and blame something in our code stack instead

[phil-allen-msft]

I think we're going to have a half dozen of these where we want to report the caller; is there a unittest to write to make sure we are detecting/rewriting info as we expect?

[ryzngard]

Unfortunately I didn't see a way to check the properties being set here. @pieandcakes do you know?

[phil-allen-msft]

I'll ask a different way. Are there reasonable unittests for GetModifiedFaultParameters to prove it extracts the stack top OR the correct depth within it, and when we add 'more' examples of frames to skip, we keep the same behavior?

[ryzngard]

That I can add, but if we can find a way to assert the fault behavior I would prefer that. If not testing GetModifiedFaultParameters is still a good test.

[pieandcakes]

We don't process the bucket parameters until PostEvent is called and then it processes them and adds them to the properties. I don't think you'd have a way to validate that the values are correct/not correct .

[ryzngard]

Got it. Should the Module be something like Microsoft.VisualStudio.LanguageServices.Razor.Test.dll or should it be the containing type full name?

[pieandcakes]

It should be FileNameNoExtensions. The code that does it today is here:

https://devdiv.visualstudio.com/DevDiv/_git/VSTelemetryAPI?path=/src/Microsoft.VisualStudio.Telemetry/WindowsErrorReporting/WatsonReportExceptionProcessing.cs&version=GBmain&line=463&lineEnd=464&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents