Receive: fix thanos_receive_write_{timeseries,samples} stats

[cincinnat]

There are two path data can be written to a receiver: through the HTTP or the gRPC endpoint, and thanos_receive_write_{timeseries,samples} only count the number of timeseries/samples received through the HTTP endpoint.

So, there is no risk that a sample will be count twice, once as a remote write and once as a local write. On the other hand, we still need to account for the replication factor, and only count local writes is not enough as there might be no local writes at all (e.g. in RouterOnly mode).

• I added CHANGELOG entry for this change.
• Change is not relevant to the end user.

Changes

Verification

[cincinnat]

@MichaHoffmann I think your fix for these metrics does not work quite right, since we need to account not for local/remote writes but for the replication factor, as far as I understand it. Could you have a look at this change?

[MichaHoffmann]

Lgtm. Can you update changelog with the fix please?

[cincinnat]

Lgtm. Can you update changelog with the fix please?

@MichaHoffmann I've updated the changelog.

[pedro-stanaka]

lg

[cincinnat]

Fixed a merge conflict in CHANGELOG

[saswatamcode]

LGTM!

[saswatamcode]

@cincinnat this also needs a slight doc update, you can do that by running make docs

[cincinnat]

The test failure seems irrelevant to the fix. It seems like a possible race condition in the test to me:
https://github.com/thanos-io/thanos/blob/main/pkg/receive/multitsdb_test.go#L468

			if test.bucket != nil {
				go func() {
					testutil.Ok(t, syncTSDBs(ctx, m, 10*time.Millisecond))
				}()
			}

There is no guarantee testutil.Ok is called before the test function exits.

[cincinnat]

Just rebased on #7694 to have a green build. Previous build failed due to the flaky test fixed by that PR.