reduce number of list calls on shared object store when using boltdb-shipper

[sandeepsukhani]

What this PR does / why we need it:
We as of now do a LIST calls per table when we need to find its objects.
If someone has a lot of tables cached locally or has query readiness set to a large number of days, it results in a lot of list calls because each querier tries to sync tables every 5 mins by default.
This PR reduces the number of LIST calls we make when using hosted object stores(S3, GCS, Azure Blob Storage and Swift) as a shared store for boltdb-shipper.

The idea is to do a flat listing of objects which is only supported by hosted object stores mentioned above.
In case of boltdb files stored by the shipper, the listed objects would have keys like /.
For each List call without a prefix(which is actually done to get a list of tables), we would build a map of TableName -> chunk.StorageObject which would be used as a cache for subsequent List calls for getting the list of objects for tables.
Cache items are evicted after the first read or a timeout. The cache is rebuilt during List call for table names or we encounter a cache miss.

Special notes for your reviewer:
I am going to send a subsequent PR to move all the code for ObjectClient and object key processing to a common package to contain all the complexity of processing the object keys, responses and delimiters with a goal to provide a simplified interface to the shipper which would have methods like ListTables, ListTableObjects etc.

Fixes #3258

Checklist

• Tests updated

[cyriltovena]

why do we evict element read from cache ?

[sandeepsukhani]

This is to avoid any possible bugs if the caller misses refreshing the cache explicitly.
The cache is integrated to make it look seamless for consumers since it only works for hosted object stores.
Removing it should not be big of a problem since we have a ttl but I just added it as an extra protection mechanism.

[cyriltovena]

but if we ask twice the same table then we will call twice List on the objectstore ?

[sandeepsukhani]

yeah but we don't have a use case where we will list objects from the same table twice. We usually circle through a list of tables for sync or compaction so we will not hit this case most likely. The only case it can happen is if someone has a really low sync interval and the non-deterministic iteration of maps in go can make the same table to be synced back to back.

[sandeepsukhani]

We can always remove this if we see it causing a problem. The problems due to stale reads would be hard to debug so I am in favour of keeping it.

[cyriltovena]

LGTM don't want to block you but I don't fully understand how cache eviction works.