Inefficiency in CoolModel class

[hugy718]

The CoolModel class is currently serve to keep various readstores in memory without loading the the actual chunk data. It looks like a caching layer, then there are a few issue to address.

• memory management: there should be a fixed capacity to control how many cube/cohort/... are loaded and when loading and processing mark how much space they take, free when no space
• methods are marked with locked with time-consuming IO inside, we should only lock only the steps that modify the cache internal structure
• there is a field called currentCube, so it can serve the cohort of a cube at one time. This is not necessary. Multiple workers should be able to concurrently request for cohorts under different cubes with only necessary synchronization

[hugy718]

One more thing. If a cube is updated and it has been cached inside CoolModel, then the old version is directly returned when requested. Needs additional checking to load the latest version.

[KimballCai]

@liuchangshiye please solve this problem together with @NLGithubWP