app/vmagent: added remote write context groups

[AndrewChubatiuk]

Describe Your Changes

Added remote write context groups

Checklist

The following checks are mandatory:

• My change adheres VictoriaMetrics contributing guidelines.

[hagen1778]

@AndrewChubatiuk do I understand correctly that with this PR I can have the following config:

# global relabeling for all incoming data
-remoteWrite.relabelConfig=/local/relabel_config.yml

# shard 1
-remoteWrite.urlRelabelConfig=shard-1/local/1_url_relabel.yml
-remoteWrite.url=shard-1/http://shard1-1/insert/0/prometheus/api/v1/write
-remoteWrite.url=shard-1/http://shard1-2/insert/0/prometheus/api/v1/write

# shard 2
-remoteWrite.urlRelabelConfig=shard-2/local/2_url_relabel.yml
-remoteWrite.url=shard-2/http://shard2-1/insert/0/prometheus/api/v1/write
-remoteWrite.url=shard-2/http://shard2-2/insert/0/prometheus/api/v1/write

based on #6212 (comment)
, where data is replicated across shards, and then replicated to each rwctx within the shard. The individual relabeling per rwctx then acts as a sharding mechanism.

In general, the workflow with new architecture is something like below:

---

Please note, specifying group name in -remoteWrite.urlRelabelConfig seems conflicting with file path.

[AndrewChubatiuk]

diagram doesn't describe code changes precise enough

1. streaming aggregation and relabeling for rwctx and group are mutually exclusive, if group name is set aggregation and relabeling will happen on a group level if not - on rwctx for a backward compatibility. there're no possible scenarios for 3 consecutive aggregations or relabelings
2. copy to each rwctx should be rather changed to copy to or shard among rwctxs