DefaultCache<T> should use a keyed lock instead of a global lock for each T

[maartenba]

Debugging what seemed like a race condition resulted in discovering DefaultCache<T> locks globally instead of per cache key. Especially in the client stores this is an issue, as retrieving and trying to cache clientA results in requests for clientB having to wait for the lock to become available.

In addition ,we found that some dependencies were registered as transient where a longer lifetime makes more sense.

This PR serves as a discussion:

• Is locking per cache key better than locking the cache altogether?
• Do we want to expand lifetimes where we changed them in this PR?

[maartenba]

Added test for the new implementation. It succeeds (yay!), and if you run it against the previous implementation it hangs for a while and then crashes with the cache lock exception.

[josephdecock]

Thanks Maarten! This is an interesting idea, and warrants further investigation. There's some other thoughts going around about experimenting with HybridCache as well.

If we take this approach, it would be a breaking change for customizations that derived from DefaultCache, so it would be something we do in a major release. Merging now would put it into the 7.3 release, so I'm marking this as "request changes", just in case.

[josephdecock]

* Is locking per cache key better than locking the cache altogether?

Probably. We do already have some granularity in the locks from the type parameter. More granularity is probably helpful especially if there are many clients. We should measure.

* Do we want to expand lifetimes where we changed them in this PR?

This looks safe to me. In general, lifetime changes can cause subtle breaking changes, so good to be careful with that.

[maartenba]

Thanks! Lets revisit during 7.3