Need to rethink CultureInfo caching #6
Description
The CultureInfoCache right now is unbound based on user input, which isn't a great idea. It does drastically improve performance however (160 RPS no caching vs. 6,300 RPS caching) so we definitely need some kind of cache here.
We could restrict the middleware from creating any CultureInfo objects that aren't explicitly allowed by the RequestLocalizationMiddlewareOptions.SupportedCultures property but that makes the middleware much harder to use OOTB. ASP.NET today (System.Web) supports the concept of auto-culture per request based on the headers, but that is limited to "known" cultures in the framework.
Windows 10 doesn't restrict the creation of cultures based on those known to the OS anymore, so the list is no longer known ahead of time. .NET Core doesn't expose APIs to retrieve the known list of cultures for this reason. In short, we can't rely on the framework to tell us what is a valid or known culture anymore, but creating such cultures is still really expensive,
So, we want a nice easy middleware that "just works" as much as possible OOTB, and we want it to be fast (cache cultures).
We could potentially generate a cache of "known" cultures ahead of time by using the .NET Framework APIs to produce the code. (e.g. Microsoft.Framework.Globalization.CultureInfoCache) This would be committed to the repo and would have to be updated as new versions of Windows come out to keep it up to date. It could also potentially be serviced if we felt that was important. Note that we need to comply to a bunch of rules if we start shipping culture lists in the box rather than deferring to platform APIs so we need to keep that in mind.
The middleware could then use this cache by default as the supported list of cultures for the app. Requests containing culture names not in the list wouldn't ever result in an attempt to create a CultureInfo so it's fast and easy to use OOTB. Of course the application would always be free to manually add additional cultures, or remove cultures, from the list itself.