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`
The longer I stare at it, the more this doesn't make sense. Why not just use entry.getValue() for the update? Are we worried about some other thread modifying it?

Also, I think that the column value should be the update time on the SlotState object. I'll elaborate at the end of this review.