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`
No. The ROLLED state column will be updated, but the timestamp which will get placed as the value will be the metric collection time which caused that slot to roll and not the server time. This fixes the discrepancy which exists currently wherein, we update the ACTIVE timestamp with metric time and ROLLED timestamp with server time. 
It helps in the convergence across multiple ingestion and rollup contexts.