Investigate using ASP.NET Core's middleware system instead of the MVC Filters

[sander1095]

Currently, we hook into MVC's filter system to run our HATEOAS code -> Take a look at HateoasActionFilter.cs
This works, but perhaps improvements COULD be made. I am not sure yet, though!

The goal of this issue is to investigate if we could use ASP.NET Core's middleware system instead. If so, we could make our code less dependent on the MVC system and thus more usable in other scenario's.

For example, something like the following (in .NET 5.0)

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app)
{
    // Other middleware here

    app.UseHateoas();

    // Other middleware here

}

The goal of the library is to run AFTER MVC is done (The request has left the controller), but before the response is sent back because we still want to populate the `Links` property of the `IHateoasObject`.

I am not sure about the order of the middleware just yet.

[sander1095]

Perhaps some more discussions need to take place before this is implemented.

For example, with our current solution we ONLY run munisio's code when it's an MVC related action. That is why we also have easy access to the DTO and hateoas object; it is a part of MVC.

If we were to use the middleware solution, we might no longer have easy access to the concrete type that is being returned, and we would potentially run our library for different types of requests that do not need HATEOAS, like static files? In this case we might optimize it with an if statement to skip our hateoas code, but how do we determine this?

In any case, I think choosing either MVC or middleware is a good solution; I do not see a reason to implement both so the user can choose, that's a bit overkill for now.

[sander1095]

Use this for inspiration: https://github.com/khalidabuhakmeh/GroupsAndFilters ?