Cleaner cache invalidation

I talked with Rich and he agrees that we should go ahead and take the risk of cleaning this up now. Pradeep, I am assigning this as the base ticket. Please talk to Jeff as Rich believes he understands the cache infrastructure best from Ambra requirements.

(In [5575]) Added an Interceptor concept for OTM Sessions. This is similar to the Interceptor support provided by Hibernate.

This is to help Ambra resolve a number of tickets related to caching. Please see #900,#901,#829,#845,#861 (and may be more)

As part of this update, please note that the Transaction API has the following additions: 'isActive', 'wasCommitted' and 'wasRolledBack'.

(In [5576]) Basic infrastructure support for transactional cache updates and cache invalidations and also support for a journal context aware second-level cache (similar to Hibernate).

Addresses #900,#901,#829,#845,#861.

CacheManager? provides a READ_COMMITTED isolation level. Only cache that is managed by this CacheManager? now is the journal context aware object-cache for OTM. No changes to existing caches or cache-invalidations yet.

(In [5638]) Undo transaction related mods from r5575. No notice from OTM on transaction state changes. Apps can directly get that from JTA. (Also note that we might remove the local Transaction support completely from OTM and only support JTA transactions.)

So Ambra CacheManager? now registers a synchronization call-back directly from JTA. In addition there is now no assumption on the spring request-scope and transaction scope being the same. (I was being lazy - thanks Ronald)

Since we can't define them as spring transaction scoped beans (no such scope provider exist currently), the beans have been converted to singleton scope and the CacheManager? manages a transaction context internally for all the caches. (ugly but works).

Addresses #900, #901.

(In [5657]) Remove SimplePageCachingFilter? and its associated cache.

The object-cache now holds the blobs that this filter was caching. Moreover the object-cache is journal context aware and will be invalidated when article is deleted/re-ingested as well as when the journal membership changes.

This closes #740,#278 and addresses #610,#901.

(In [5659]) Remove Single-Annotation from article-annotation-cache. Object-cache contains this. Addresses #901.

(In [5669]) Make the old field values available in change notifications.

Addresses #901.

(In [5670]) Invalidate the annotation-list for an article in article-annotation-cache when an article is deleted or when any article-annotation that annotates that article has changed. Addresses #901.

(In [5671]) One more to the invalidation rule in r5670. The list in cache is maintained for article-annotations also, not just articles. Addresses #901.

(In [5675]) Invalidate citation cache entries in article-annotation-cache on an article delete. Addresses #901.

(In [5678]) Get rid of the cache entries for secondary objects and tables-and-figures from the article-annotation-cache. object-cache contains these already.

Addresses #901.

(In [5680]) Get rid of Article object from article-annotation cache. Already covered by object-cache. Also cleaned up the serialization hacks related to caching of the Article object. Addresses #901.

(In [5681]) Set up invalidations for transformed-article. Get rid of all manual invalidations. Addresses #901.

With this the article-annotation-cache related changes are complete. This cache only contains 3 types of entries now : annotation-list, transformed-article and citation-info. The citation-info should go away with #921.

(In [5689]) Convert journal and carrier cache into transactional cache. Also cache invalidations are based on change-listeners - instead of relying on manual notifications sprinkled all over.

As part of this change, Journal service has been split into three:

• the JournalKeyService? - key to id mapping for journals
• the JournalFilterService? - maintains OTM filter rules
• the JournalCarrierService? - reverse mapping from objects to journals

WARN: only tested on SingleBox? install.

Addresses #900, #901.

r5693 is the last of the changes. With this all notifications are tied to OTM.