Ignore the test filter for RunWindowsAzureFunctionsTests

[bouwkast]

Summary of changes

This removes the ability to change the test filter that is used when running the Azure Functions Tests and it will just fallback on the default values.

Reason for change

When someone sets the test filter for a CI build to something that requires a sample project that is not an Azure Functions sample app this stage will fail at it cannot find the sample application as only Azure Function samples are build prior to this stage.
We don't build all of the sample applications when running these as that takes significant time.
We have these in their own stage because they are a pain to build and test.

19:09:24 [ERR] Target RunWindowsAzureFunctionsTests has thrown an exception
Nuke.Common.Tooling.ProcessException: Process 'dotnet.exe' exited with code 1.
   > C:\dotnet\dotnet.exe test D:\a\_work\1\s\tracer\test\Datadog.Trace.ClrProfiler.IntegrationTests\Datadog.Trace.ClrProfiler.IntegrationTests.csproj --configuration Release --framework net7.0 --filter QuartzTests --logger trx --no-build --no-restore --results-directory D:\a\_work\1\s\artifacts\build_data\results\Datadog.Trace.ClrProfiler.IntegrationTests --settings D:\a\_work\1\s\tracer\test\test.settings /property:Platform=AnyCPU
   @ D:\a\_work\1\s
Error output:
   [xUnit.net 00:00:04.64]     Datadog.Trace.ClrProfiler.IntegrationTests.QuartzTests.SubmitsTraces(packageVersion: "") [FAIL]

Implementation details

.SetFilter just always uses the default.

Test coverage

Other details

Can likely fix this betterer some how, maybe just a new separate test filter, but I actually don't know how often we actually are filtering the Azure Functions tests.

[bouwkast]

Issue came up in #7192 when doing a comprehensive test run scoped to those tests.

https://dev.azure.com/datadoghq/dd-trace-dotnet/_build/results?buildId=188384&view=logs&j=e20f8990-7a08-508f-0f98-44b28840f02f&t=fbb31288-d900-5e20-8301-48813c5a9984

[NachoEchevarria]

Thanks!

[andrewlock]

Thanks for trying, but I'm not sure this will actually solve the problem? 🤔

[andrewlock]

🤔 Will this actually solve the problem? The problem is typically that we're not building the same apps. With this change, it means we will always run the azure functions tests, but that won't change the fact that we aren't building the samples, right?

On the assumption that you always specify both, maybe we should actually just always & these instead? e.g.🤔

Suggested change

	.SetFilter("(RunOnWindows=True)&(Category=AzureFunctions)&(SkipInCI!=True)") // FIXME: ignoring the global Filter as when set it may cause issues
	.SetFilter($"(RunOnWindows=True)&(Category=AzureFunctions)&(SkipInCI!=True){(string.IsNullOrWhiteSpace(Filter)? "" : "&" + Filter)}")

[bouwkast]

Yeah I thought about this over the weekend and would rather not do this at all and just let it fail, I think it is a reasonable failure for some PRs as we don't do this that much so asking to re-run the normal pipeline is better (or ideally getting it to not link to the PR at all) - I wasn't sure how the build was actually ran.

[bouwkast]

Closing as can just re-run the normal pipeline