V10: Fix request accessor memory leak

[nikolajlauridsen]

This PR fixes #13098.

As described in the issue there was a memory leak in AspNetCoreRequestAccessor

The reason for this memory leak was that it was set up as a notification handler, which is transient. This meant that every time a request was sent, a newAspNetCoreRequestAccessor was initialized, and an OnChange even registered on the IOptionsMonitor, this meant that the AspNetCoreRequestAccessor alongside its delegate in the IOptionsMonitor would never be GC'ed.

To add insult to injury, since the notification handler is transient, the _isInit and _hasAppUrl would re-default to false each time, meaning that GetApplicationUrl is called unnecessarily on every request.

Unfortunately, this is not that simple to fix in a nice way without breaking changes. What I've done is implement IDisposable on the AspNetCoreRequestAccessor, this allows us to unregister our OnChange when disposing notification handler, meaning no more hanging references 🎉.

Additionally to fix the initializer issue I've created a new class ApplicationUrlRequestBeginNotificationHandler which then calls the EnsureApplicationUrl, making sure we're using the singleton instance of AspNetCoreRequestAccessor.

Testing

I've tested in this way, and everything seems to be working great.

1. Send a lot of requests to the frontend, and take a memory snapshot, and ensure that there's not a bunch of AspNetCoreRequestAccessors in memory
2. Set a breakpoint and ensure that GetApplicationUrl is only called once, not on every request.

These was my results:

v10/dev dev after sending ~32k requests:

This branch after sending ~34K requests:

As you can see, prior to this branch we'd have ~32K instances of AspNetCoreRequestAccessor in memory, on this branch, there are none.

[kjac]

@nikolajlauridsen lovely 😄 make the new handler internal and the new EnsureApplicationUrl() method likewise as we just discussed, then it's all good 👍