Make the EfMap mapping cache thread-safe

[gentledepp]

EfMap.Get(DbContext) caches one DbMapping per model in a static Dictionary, reading it with TryGetValue and writing it with an unsynchronised indexer assignment:

private static readonly Dictionary<string, DbMapping> Mappings = new Dictionary<string, DbMapping>();

public static DbMapping Get(DbContext context)
{
    ...
    if (Mappings.TryGetValue(key, out var value)) return value;
    value = new DbMapping(context);
    Mappings[key] = value;
    return value;
}

Two threads arriving on a cold cache can read that dictionary while another is writing it, which throws or returns the wrong entry.

Why it is hard to recognise

The failure does not look like a dictionary problem, because it surfaces in one of two disguises:

• Exception: No table mappings provided. — MappedDataReader<T>'s constructor resolves each derived type inside a try { } catch { }, which it has to do so that unmapped derived types are skipped. A mapping lookup that blows up is therefore swallowed per type, and the resulting empty collection is reported as if the model were wrong. That sends you looking at your entity configuration rather than at a race.
• NullReferenceException out of Dictionary.Insert — the corrupted-internal-state signature. In our case this also took the whole test host down mid-run, with no failing test reported.

Reproduction

An EF6 integration suite with fixtures running in parallel, several of them bulk inserting. Serially it passes; concurrently it fails intermittently with the message above. Adding a locked warm-up that builds the cache once before the parallel work starts made it go away, which is what pointed at the cache rather than the model.

It only needs concurrent first use, so it is rare in a long-running app and much more likely in a test suite or a job host that starts several workers at once.

The change

ConcurrentDictionary and GetOrAdd.

Two threads may still each construct a DbMapping on first use, with one result discarded. That is wasteful but correct — and unlike a Lazy<T> it does not cache a failed construction, so a transient failure while building the mapping does not poison the entry for the lifetime of the process.

DbMapping's constructor maps the whole context eagerly and the instance is only read afterwards, so once an entry is published there is nothing further to synchronise.

Scope

This is not test-only: any application that bulk inserts from more than one thread — concurrent background jobs, or requests — can hit the same window on first use.