RFR: Fix rollup failure for delayed metrics bug

In https://github.com/rackerlabs/blueflood/pull/372 I proved that rollups do not work as expected for delayed metrics. After investigation, I noticed that the shard state was not being persisted and read as expected. This PR fixes the bug by doing the following changes:

1. While persisting the shard state, `AstyanaxWriter` was using the collection time of the metric to decide the column timestamp. If a delayed metric is received with collection time lower than when the last active UpdateStamp, the update will never be picked up by rollup slave because the cassandra timestamp of the update will always be of lower value than the currently existing one. I changed to use the current time instead.
2. When `ShardStatePuller` pulls the state changes from cassandra, it used to take an update only if the current UpdateStamp was lower than UpdateStamp being pulled. This again prevents the slot update belonging to a delayed metric from taking effect. I changed this logic which exists in `updateSlotsOnRead` method of `SlotStateManager` and have provided a detailed explanation in the comment before the block of code.
3. Rollup slave used to stamp the UpdateStamp to be the server time rather than the metric time. I changed it to use the metric UpdateStamp timestamp, this is important to have convergence between concurrent ingestors and rollup slaves.

To prove that it works I have added tests to `ShardStateManagerIntegrationTest`
Thinking about this more... I think if we are selective about what updates make it back into the DB, this is a good change. However, if we just dump everything (like possibly stale values) when pushing, this would be bad.