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?

I am not sure I get your question correctly. But `entry.getValue` will give the `UpdateStamp` object, but `SlotState` takes only the `UpdateStamp.State` in its constructor, with a setter method for timestamp. Also, serializer for `SlotState` will serialize only `Gran, Slot, State` which will be column key and we set the column value explicitly to be the UpdateStamp.timestamp.
LMK if I have still not answered your question.