Fix cache build for honoring mapped concurrency

[fredericDelaporte]

This PR is a follow-up to #1476. It aims at fixing:

• The resolved concurrency strategy. Currently, when two entities share the same region but have a different concurrency strategy, the first having its cache built will "force" the other to use the same concurrency. (This trouble was not occurring for collections caches.)
• The duplication of cache concurrency strategies: currently each cached collection recreate its cache concurrency strategy without checking if one has already been built for its region. (Entities do check instead.)

Possible breaking change: ICache caches yielded by the session factory will be a CacheBase wrapper around the cache actually provided by the cache provider, if it was not deriving from CacheBase.

[hazzik]

I think this refactoring went a wrong way. (But I'm not sure what is the right way).

[fredericDelaporte]

I think this refactoring went a wrong way.

It is not just a refactoring, it is a bug fix. We currently have bugs, like resolved entity concurrency not matching the one put in mappings.

A refactoring could be extracting the cache handling out of the session factory, as Hibernate has done (but without fixing the bug mentioned here). But their refactoring is not easily portable to NHibernate, because it looks heavily coupled and even duplicated in their many cache providers (ehCache, singleton ehCache, infiniSpan, ...).

Can you explain what seems wronger in this PR than current implementation in master? I do not think this solution is perfect, but I think it is more correct. If there are troublesome points in it, it is of course always worth pointing them for checking if we can do better.

But after that, even if we find no way of getting those points better, we should then check if overall we agree this PR is still be better than current implementation. And if yes then we should accept it, don't you think?

[hazzik]

wronger

Didn't know such a word exists.

Can you explain what seems wronger in this PR than current implementation in master?

I did not say that this is worse than the master, I just feel that this is a wrong way, but don't yet know why. I'll take another look later this week.

[hazzik]

I've added some improvements and also I've removed some of the logic which I think unnecessary. You can drop it if you do not like.

[fredericDelaporte]

I will address the life-cycle trouble.

[fredericDelaporte]

Thanks for your changes. After having moved the destroy handling, LGTM.

[fredericDelaporte]

Rebased, and obsolete comments version updated.

[hazzik]

LGTM