CASSANALYTICS-177: Add instanceId query parameter to fix HTTP 421 err…

[bianca-stanciu29]

…ors when Sidecar is behind a load balancer

[skoppu22]

This PR stamps the same instanceId on every request — so if the job writes to more than one instance, all but one get mislabeled.

Example:
Setup (a normal 3-node bulk write)
Cassandra ring: instance 1 | instance 2 | instance 3
Sidecar (one config knows all 3, ids 1/2/3), fronted by a load balancer at sidecar-lb:9043
Operator sets: spark.cassandra_analytics.sidecar.instance.id = 2
The writer builds ONE client over all three (CassandraContext.java:90):

AnalyticsSidecarClient.from(new SimpleSidecarInstancesProvider(clusterConfig /* 3 instances */), conf)
Copy
What happens per request (with this PR)
request meant for instance 1 ──▶ ...?instanceId=2 ──▶ server: instanceFromId(2) ──▶ instance 2 ❌ WRONG
request meant for instance 2 ──▶ ...?instanceId=2 ──▶ server: instanceFromId(2) ──▶ instance 2 ✅ right
request meant for instance 3 ──▶ ...?instanceId=2 ──▶ server: instanceFromId(2) ──▶ instance 2 ❌ WRONG
The ?instanceId=2 overrides the Host header on the server, so the server confidently routes the instance-1 and instance-3 work to instance 2. Because config.instanceId() is a single job-global value, vertxRequest(...) applies it uniformly even though it already knows the real target (sidecarInstance) and could distinguish them.

Net: a fixed id is only correct when the job touches exactly one instance. For any real multi-node ring it silently misroutes → the data-correctness risk behind the WARNING.

[bianca-stanciu29]

hi @skoppu22
Thanks for flagging this, it's addressed now.

vertxRequest prefers the target instance's own resolved id over the job-level one, for
any ring size (not just 3): if every instance is individually addressable and tagged via
host[:port]=<id>, each request gets the right id regardless of instance count. If any
instance isn't resolved, validateSidecarInstanceIdCoverage fails fast with a clear error
instead of silently misrouting.

To be upfront: your exact topology, multiple instances behind one shared address, still
can't work with this PR alone, at any scale. A hostname-keyed lookup can't disambiguate targets sharing one address; it now fails fast with "Duplicate key" instead of resolving(see testSidecarInstanceIdsByHostnameThrowsWhenSharedHostnameHasDifferentIds).
Making that work needs Sidecar to report each instance's own id in the ring response, tracking that as a follow-up.

This is the same gap you flagged on #223 (CASSANALYTICS-181), single-cluster jobs behind a load balancer hit it too, and a real fix should cover both paths generically rather than being patched per-PR.
Appreciate a re-review when you get a chance.