fix: crrect initialization of a few slices

[seiyab]

What this PR does / why we need it:
I found suspicious slice initialization so fixed them.
These slices are initialized by make([]type, size). But their contents are filled by slice = append(slice, newElem). It should result leading zero values.
Say,

xs := make([]int, 3)
xs = append(xs, 1)
xs = append(xs, 2)
xs = append(xs, 3)

will result xs = []int{0, 0, 0, 1, 2, 3}. Probably it's unintentional and means

xs := make([]int, 0, 3)
xs = append(xs, 1)
xs = append(xs, 2)
xs = append(xs, 3)

Which issue(s) this PR fixes:
N/A. I consider it's a trivial fix.

Special notes for your reviewer:
Feel free to reject this PR.I'm sorry but I'm not familiar with Loki. I found it just scanning Loki with my experimental static checker.
I've read codes around these lines and callers of them. I suppose that they have confusion between length and capacity but I don't understand what they do in context of entire application.
Anyway, I suppose leading zero values look unintentional and tests pass.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
  • Need you help if new tests are required
• Title matches the required conventional commits format, see here
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
  • Need your help. I'm not sure. I guess it's not user-facing because tests passes without any change. My hypothesis is that zero values are dropped implicitly by callers.
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[CLAassistant]

All committers have signed the CLA.

[cstyan]

this seems like a good change, AFAICT atm we could be allocating # of ingesters * 2 uint32's since we could have a response from every ingester

[cstyan]

this also seems safe, but actually I think it should be len(perJobResults) should it not? @bboreham I'm not sure from your original PR (here) if you intended to create the slice of chunkBySeries length rather than perJobResults length

[seiyab]

No, len(chunksBySeries) looks correct. I also feel len(perJobResults) is correct at first sight.
Actually, argument of append is innerSlice..., not innerSlice. And sum of their length is probably len(chunkBySeries) (groups := make([]chunkGroup, 0, len(chunksBySeries)/c.chunkBatchSize+1).

[cstyan]

Ah you're right, I misread the append line 👍 good find

[seiyab]

Thank you for kindful & speedy review!