Describe the suggested improvement

Currently ServicePulse for Windows is a .NET Framework 4.8 application in ServicePulse.Host.csproj. It uses OWIN which is .NET Framework only and definitely out of favor. It's also installed by Windows-only Advanced Installer.

On the other hand, the Linux container in ServicePulse.csproj is a .NET 8 application using Kestrel. It also includes YARP allowing it to reverse proxy the ServiceControl API and Monitoring API enabling ServiceControl and ServicePulse to be hosted together on one domain+port, allowing authentication/authorization schemes (including OpenID login flows) to secure it.

A next major version could include various improvements and cleanups not possible in a minor version:

• Unify the hosting between Windows/Linux as one project using Kestrel.
• Bring the reverse proxy features to the Windows application as well.
• Evaluate whether AdvancedInstaller is truly needed. (It's not awesome.) Might be sufficient to just document how to install it as a service with sc.exe
• The app.constants.js file does not need to be written to disk if it's implemented as a controller action, and then it can be driven by environment variables.
• Could make it self-contained so it doesn't require a specific version of .NET, and we could ship various OS variants so developers on any platform could just run ServicePulse without needing to install it as a service.

Some cleanup that should occur:

• Redesign running as service to cooperate with AspNetCore norms
• Evaluate if ExtractCommand is still relevant and reimplement if needed. Maybe the HTML/CSS/JS can just be an additional build artifact.
• Re-evaluate necessity of remaining commands
• The setting for Monitoring URLs is implemented as an array, but we only ever look at the first item of that array. This is needlessly complex.
• There's code in ServicePulse that checks for what versions of ServiceControl it will talk to. We can probably bump that up to ServiceControl 6 or later, and could clean up a lot of cruft related to supporting older ServiceControl versions.
• Any client-side code related to Internet Explorer could be eliminated.
• Remove tons of OWIN code that is all available out-of-the-box in AspNetCore.

Additional Context

No response