Extensible Filters + AggregateFilter

[thomhurst]

WIP.

Fixes #3530
Fixes #3590

Changes:

• Remove ITestExecutionFilterFactory - Filters can just be registered directly on the test application builder via a delegate. They can access the service provider if they like.
• Test filters expose an IsAvailable property (I dunno what to name this? IsAvailable? IsActive?) to tell the framework whether it has been requested as a filter for this test run
• Filters are then selected only if IsAvailable is true
• The filter implementation is built just before being passed to the framework with the following logic:
  • If there are test nodes passed to the execute request, then we build a test node uid filter
  • If there is a single IsAvailable filter, we pass that to the framework
  • If there is no available filter, we pass a NopFilter to the framework
  • If there are two or more available filters, we construct an AggregateFilter, and the filters are passed in as inner filters which can be accessed via a ITestExecutionFilter[] array inside AggregateFilter

Framework authors can now also create their own filters and register them.

• They create a filter that implements ITestExecutionFilter.
• They then call TestApplicationBuilder.TestHost.RegisterTestExecutionFilter(...)
• If IsAvailable is true for that filter, it'll be passed into the framework

[thomhurst]

@Evangelink Hope you don't mind me having a go at tackling a couple of issues that have been sitting around for months?

Microsoft.Testing.Extensions.Retry isn't open-source/in this repo? Got failing tests because I've changed code, but that's in a package it seems so I can't make changes to it?

[thomhurst]

Same happening with integration tests

Unhandled exception. System.TypeLoadException: Could not load type 'Microsoft.Testing.Platform.Requests.ITestExecutionFilterFactory' from assembly 'Microsoft.Testing.Platform, Version=42.42.42.42,

Why does it reference packages instead of the local project's code?

[thomhurst]

@Evangelink @nohwnd @MarcoRossignoli Providing you were okay with implementing this, how would I go about being unblocked due to private/internal code that I can't edit?

[Evangelink]

@thomhurst I wasn't able to play a little with the PR but although I like the concept of the aggregate filter, I don't think that the extensibility as you are doing it is the right way forward as it would allow users to register any kind of filter including filters that are not handled by the framework. As of now, the filters have to be specifically supported by the platform or the framework.

[thomhurst]

Hmm that's a good point. The registration code is going to have to be surfaced publicly though in order for frameworks to register it.

Might be that filters work in conjunction with capabilities? So filters are only considered active/available if the framework has a capability for it? Kinda like the trx extension. That way we know a framework can handle that filter.