First set of tests for the BFF using aspnet Aspire

[Erwinvandervalk]

This PR adds tests to the BFF using aspnet aspire as a host.

There were some challenges with implementing this PR. These challenges are addressed below.

There are 3 modes in which you can run the tests:

1. Directly. Then the test fixture will launch an aspire test host. It will run all tests against the aspire test host. In order to make this work, there were two things that I needed to overcome (see below). Service Discovery and Shared CookieContainers.
2. With manually run aspire host. The advantage of this is that you can keep your aspire host running and only iterate on your tests. This is more efficient for writing the tests. It also leaves the door open to re-using these tests to run them against a deployed in stance somewhere in the future. Downside is that you cannot debug both your tests and host at the same time because visual studio compiles them in the same location.
3. With NCrunch. It turns out that NCrunch doesn't support building aspire projects. However, I've always found that iterating over tests using ncrunch is the fastest way to get feedback. So, to make this work, I had to add a conditional compilation.

Service discovery

Aspnet Aspire pushes you to use service discovery. When you 'normally' run an application, it will respect the url's configured, but when you run a test host, it will launch all the services with randomly generated ports. I have not yet found a way to disable this behavior.

Service discovery works like this:

1. In aspire you configure which services are using which other services. Aspire will start the services and inject the url of the services as a configuration setting into the consuming services.

2. For normal situations, it will then register a HTTP handler that will resolve a url that contains the 'name' of the service with a url that contains the actually used URL. This works well for http clients that are retrieved from the httpclientfactory. But not all of them are. For example, the handlers that are added for the .AddOpenIdConnect() method are NOT resolved from here. Also, you'll need the authority name resolved manually.

Fortunately, you can can also manually get the urls by calling the ServiceEndpointResolver. This does mean that configuring certain services (such as adding clients to identity server and adding the openid connect configuration) become a lot more complex.

Overcoming shared cookie containers

This PR is all about automated tests using HTTP Client. It turns out that aspire will return you a HTTP Client for testing purposes that's already configured to connect to the correct service. However, there is no way to get the underlying HTTP Client Handler. This can cause problems because the underlying SocketHttpClientHandler is cached and reused. If you configure it to use cookies, then cookies are shared across multiple tests. This is obviously not desired.

So, in order to overcome this, I've manually created the infrastructure needed to store / send cookies, to follow redirects and to perform request logging. Then I've created a wrapper http handler around the http client. The underlying http client is configured NOT to use cookies and automatic redirection. Now this is fully under our control and the tests run fine.

Conditional compilation for NCrunch

Unfortunately, NCrunch does not support Aspire. However, Ncrunch is the fastest and most convenient way to run integration tests against an already running host. In order to make this work, I've added a conditional compilation step. When running under ncrunch, the testfixture will bypass anything to do with aspire and will simply perform http requests.

This is purely because NCrunch is not capable of even building the aspire project.