perf: improve allocations in OwinEnvironment

[DeagleGross]

OwinEnvironment allocates a Dictionary<string, FeatureMap> with at least 23 entries of string and FeatureMap objects per request.

In most cases, Owin abstraction is used only to get the data in the specific format (i.e. access the HTTP method via OwinConstants.RequestMethod key), but not to remove \ add entries or rebuild the whole FeatureMap dictionary.

Therefore I am introducing the OwinEntries class (not visible to users), which allocates the static readonly entries dictionary (similar to what existed before) and uses that for the key-value access (so a single allocation per app lifetime against the per-request allocation). However, OwinEnvironment has a rich API to modify the dictionary (i.e. remove entries or clear them completely). Therefore I am doing the following to fully support existing API and dont introduce breaking changes:

1. for API OwinEnvironment.FeatureMaps returning IDictionary<string, FeatureMap> there is no way to securely determine if the dictionary instance will be changed, and because of that we can't avoid performing the deep-copy of static _entries (same perf loss as existed). Next interaction with OwinEnvironment will be using _contextEntries (request-lifetime) instead of static _entries.
2. for API OwinEnvironment.Remove(string key) I am using a separate HashSet<string> _deletedKeys to keep track of deleted entries per request lifetime. Even if all original entries are deleted, this is still a more lightweight flow than existed before
3. for API OwinEnvironment.Clear() I am falling back to _contextEntries usage (request-lifetime)

Note: there are some FeatureMap objects, which are dependent on the HttpContext passed into OwinEnvironment, so I keep them separately in a dedicated Dictionary<string, FeatureMap>. It's contains a single entry so far.

I have added the microbenchmark (see PR), with a code that performs multiple requests using the default HttpContext, and used the new OwinEnvironment implementation against the old one:

    [Benchmark]
    public async Task ProcessMultipleRequests()
    {
        foreach (var i in Enumerable.Range(0, 10000))
        {
            await _requestDelegate(_httpContext);
        }
    }

Benchmark results:

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
OwinRequest_NoOperation (old)	27.46 ms	0.508 ms	0.821 ms	2750.0000	62.5000	-	133 MB
OwinRequest_AccessPorts (old)	29.45 ms	0.577 ms	0.931 ms	2750.0000	62.5000	-	133 MB
OwinRequest_AccessHeaders (old)	28.52 ms	0.565 ms	1.344 ms	2781.2500	93.7500	-	133 MB
OwinRequest_NoOperation (fix)	6.162 ms	0.1208 ms	0.1984 ms	234.3750	-	-	12 MB
OwinRequest_AccessPorts (fix)	6.388 ms	0.1219 ms	0.1304 ms	234.3750	-	-	12 MB
OwinRequest_AccessHeaders (fix)	6.478 ms	0.0921 ms	0.0817 ms	250.0000	-	-	12 MB

(thanks to @deanward81 for the idea)

Closes #58916

[DeagleGross]

TODO:

• include DictionaryStringValuesWrapper and DictionaryStringArrayWrapper enumerator improvements
• improve allocations for port string conversion

[mgravell]

if immutable dictionary is available, I wonder if we should use that instead, to advertise 100% "this will not change"; alternatively (other than for the deferred per-context populate, which might need thought), I wonder if this could just be a switch expression...

[DeagleGross]

changed type of _entries to IReadonlyDictionary<string, FeatureMap> + creating the _entries as ImmutableDictionary to completely make sure we are not breaking the shared-state dictionary.

[mgravell]

Union isn't free; probably isn't an issue, but this might be something to check the impact of in pathological cases; since you have two dictionaries, it might be more efficient to hand roll this with a foreach and ContainsKey / TryGetValue

[DeagleGross]

rewritten into 2 consequent foreach loops

[mgravell]

concept looks solid, nice; added some thoughts

[danmoseley]

could you please resolve conflict @DeagleGross