Add an IChangeToken to IServerAddressesFeature

[halter73]

Is your feature request related to a problem? Please describe.

This is a followup to #19376. HttpSys and now Kestrel both support reconfiguring endpoints at runtime. When an endpoint is added or removed, the IServerAddressesFeature is updated to reflect this changes. Unfortunately there is no way to observe when the IServerAddressesFeature changes today.

Describe the solution you'd like

We should add an IChangeToken to IServerAddressesFeature so app developers can have a way to react to server endpoint reconfiguration.

[analogrelay]

Or just a CancellationToken. As part of the extensions migration we had a discussion about change tokens and while we can't justify removing them, it's probably not necessary to keep them. Unless we need to compose with one from config (which I guess we might have to)

[Tratcher]

CancellationTokens don't have convetions for firing multiple times, which we would need here.

[analogrelay]

I seem to remember we had discussed ways to handle that. Adding @stephentoub and @davidfowl

Regardless of that, I'm supportive of the general idea (signalling changes to addresses). We just need to figure out the right primitive to use.

[davidfowl]

I wouldn’t stop using IChangeToken as yet. I’d hate to bring inconsistency here especially since the config system already exposes it. Either we expose an event or an IChangeToken

[analogrelay]

Fair enough. Just wanted to raise the issue.

[analogrelay]

Triage: Backlogging until we have a motivating scenario (from customer, YARP, etc.)

[analogrelay]

One example of a change that might be needed here: HttpsRedirectionMiddleware only reads IServerAddressesFeature once. If it changes, the middleware will need to know to re-read it.

[halter73]

In light of my thoughts in #41737, maybe it should be a new service type that has a read-only list of addresses and an IChangeToken. This would have the additional benefit of being able to consume from application code.