Volume KV caching layer

[clintkitson]

Today all volumes that are processed travel through a filter that performs KV lookups. Doing these in the fashion that must be done can be very expensive. An idea here could be to introduce a caching layer that sits above the KV store to ensure all lookups occur from memory instead.

This is starkly different than any proposal that introduces a caching layer that would sit in front of the backend libStorage queries for authoritative storage platform information.

[clintkitson]

This also introduces a front end challenge where since the KV is no longer completely authoritative for Polly, then HA solutions that are coordinated at higher levels are much more important.

[davidvonthenen]

Added the beginnings of benchmark tests for KV store. Will need this in order to see if we are improving the performance (or not). The idea is that any insert or update you have no choice but to take the hit, so all performance testing is looking to improve queries only.

PR: #130

vonthd@Davids-MacBook-Pro:~/go/src/github.com/emccode/polly/core/store$ go test -bench=.
PASS
BenchmarkGetVolumeIDNotExist-8 20000 78343 ns/op
BenchmarkGetVolumeIDs-8 20000 88255 ns/op
BenchmarkNewVolumeMetadata-8 100 14589506 ns/op
BenchmarkUpdateVolumeMetadata-8 1000 1388182 ns/op
ok github.com/emccode/polly/core/store 8.349s