This property was added when ASF 2FA existed in solo + import mode, and the purpose was automatic accept of confirmations in solo mode. Due to the fact that ASF 2FA exists only in import mode, and user should be using authenticator of his choice for all 2FA-related tasks, this properly is no longer in ASF 2FA scope, and should be removed to avoid confusion. Yet another reason for this is the fact that it actually didn't work since quite a while, together with SendTradePeriod.
In very rare scenario of starting from time X, calculating SteamTimeDifference of Y, then changing time from X to Z, old Y difference might no longer be accurate, which could lead to temporary failure of generating tokens/confirmations for given time.
Steam accepts tokens for quite a while (15 minutes from their time IIRC), so this would only hit us if we started from really huge time gap X, and not just normal typical small max 1-2 minutes updates.
Now this is a nice bug that was found accidentally by ArchiBoT...
ReaderWriterLockSlim() is very decent solution, but it's thread-based, and we're using our ConcurrentHashSet in mixed async/sync context. This means that if we use something like:
foreach (var item in concHashSet) {
await AnythingAsync().ConfigureAwait(false);
}
It's totally possible that we'll request read lock as thread 1, and release the read lock as thread 2, which will lead to RWLock exception => System.Threading.SynchronizationLockException: The read lock is being released without being held.
Fortunately it looks like we didn't have any scenario like this in ASF, as this was possible only when we async/await while enumerating over ConcurrentHashSet, so that specific bug didn't affect ASF codebase (yet). Still, I must fix this as current implementation is not thread-safe, so our HashSet is in fact not concurrent in the first place.
I analyzed possible solutions and there are basically 3: either using ConcurrentDictionary and wrapping around it, replacing lock with SemaphoreSlim, or using third-party AsyncReaderWriterLock from StephenCleary. SemaphoreSlim entirely kills the concept of multiple readers one writer, and could affect performance negatively, moreover - it doesn't support upgreadable lock scenario we have with ReplaceIfNeededWith(). Concurrent dictionary would be nice if I didn't have that awful memory hit from storing mandatory pointless value, plus I don't really like concept of wrapping around conc dictionary if I can simply use it right away and drop my conc hashset entirely. AsyncReaderWriterLock seem to be really well written, and works on Mono + should be compatible with .NET core in the future, so we should go for it as it's the best bet both performance-wise and memory-wise.
This brings another package dependency and changes a bit backend of ConcurrentHashSet
