[bugfix] fixes issues sharding series by storageref vs fingerprint in…

[owen-d]

… stripeSeries

I noticed a concurrent map read/write panic coming from our stripeSeries code at

github.com/grafana/loki/pkg/storage/stores/tsdb.(*stripeSeries).getByID(0xc0f7f52a00, 0x2?)

Reading over the code, I realized we were using the same lock index during Append calls, which is incorrect. To fix this problem and make the code a bit easier to work with, I embedded RWLocks in both the seriesHashmap and the memSeriesMap. This way, we don't reuse the same locks for both purposes, as the seriesHashmaps are sharded by fingerprint whereas the memSeriesMaps are sharded by StorageRef.

ref #5428

[grafanabot]

./tools/diff_coverage.sh ../loki-main/test_results.txt test_results.txt ingester,distributor,querier,querier/queryrange,iter,storage,chunkenc,logql,loki

Change in test coverage per package. Green indicates 0 or positive change, red indicates that test coverage for a package fell.

+           ingester	0%
+        distributor	0%
+            querier	0%
+ querier/queryrange	0%
+               iter	0%
+            storage	0%
+           chunkenc	0%
+              logql	0%
+               loki	0%

[sandeepsukhani]

LGTM