Factored out WeakDictionary in favor of weak events using Prism.Core

[NightOwl888]

Closes #256, #604, and #605.

This removes the Lucene.Net.Support.WeakDictionary<TKey, TValue> class (and its tests) that were carried over from Lucene.Net 3.0.3, and completely replaces it on .NET Standard 2.0 and .NET Framework with ConditionalWeakTable<TKey, TValue>. Since the enumerator was not available on .NET Standard 2.0 and prior, this workaround uses weak events from Prism.Core to either call methods or return strong references to types that are inside of the ConditionalWeakTable<TKey, TValue>.

This adds an AddOrUpdate extension method (non-threadsafe) for cases where a "put" is required.

Also adds Lucene.Net.Util.ExcludeFromRamUsageEstimationAttribute to mark fields so they don't get included in the calculation (which prevents infinite recursion on the event fields).

[rclabo]

WOW! You are amazing!

[laimis]

I second the WOW! comment, can't believe you find a solution for this...

[eladmarg]

Even though it's not relevant for me (I'm using net core for years),
I'm really curious, did this solve the memory leak issue?

[NightOwl888]

@eladmarg

Not sure. Being that ConditionalWeakTable requires the key and values to be dereferenced before it will clean them up, this poses a problem to be able to check whether they actually still exist (because they cannot be looked up without those references). So, maybe the only way to check is to profile/benchmark the app to see if it makes a difference, but other suggestions are welcome.

However, testing on .NET Framework seems to have settled at around 1-2 min longer than .NET 5, where before it varied and was for the most part around 14 minutes instead of around 11-12 minutes.

[NightOwl888]

I have altered this a bit:

1. The events were migrated to a new Lucene.Net.Util.Events internal static class.
2. Removed the GetRamBytesUsedEvent and GetDocIdSetsEvent and reused the GetCacheKeysEvent in these cases, looking up the values from the ConditionalWeakTable based on the keys. While this makes the event functionality a bit slower, it avoids putting DocIdSet and CachedOrds objects into the finalizer queue and shifts the responsibility of cleaning up events to IndexReader.Dispose(). This method is almost certainly guaranteed to be called by the consumer, which takes it out of the finalizer queue.
3. Changed the event tracking to allow multiple instances of the same event to be attached to an IndexReader instance, which solves any potential limitations if the same IndexReader instance is involved in 2 or more different contexts that require events.

So, this basically avoids any finalizer calls to enable the weak event functionality.

But even if that were not so, avoiding the huge overhead of re-allocating a Dictionary repeatedly by relying only on ConditionalWeakTable and weak events is certainly more efficient than WeakDictionary.