Feature bit cache warming

[kbuckler]

As discussed. A cache miss may cause all feature bits to be preloaded, up to Arturo.cache_warming_limit.

A cache miss that does not find the requested feature bit in the database will not cause this to happen. This is intentional.

[jamesarosen]

Doesn't this warm the cache every time the cache misses but the database has the record, not just the first time?

[kbuckler]

Yeah, that's right though something may have gotten lost in translation from my other pull request. Each cache miss + database hit preloads all other records.

I suppose this might be a problem in some environments, where the cache isn't in-process.

[jamesarosen]

Either I'm totally misreading this or you're missing my point.

1. User requests a feature, foo
2. feature_cache_warming_enabled returns true
3. warm_feature_cache loads the most recent 150 records
4. but foo isn't one of them, so it's never written to the cache
5. later, another user requests foo
6. we again load the 150 most recent features, and foo still isn't among them, so it isn't cached

[kbuckler]

Nope, you didn't misread, that's actually a good point. That will happen when foo is older than cache_warming_limit other records. But my earlier statement still stands, that each cache miss and database hit sequence will preload all other features, up to the configured limit.

I'm thinking that the cache_warming_limit isn't necessary, and might even be problemsome in other ways. Chances are if we hit that in the future we'll just increase it and move on without second thought.

[kbuckler]

Squashed.

[jamesarosen]

Now we need to port this to the main branch...