[scd] Add hash lock option

[the-glu]

This PR follow #1518 as it increase performance of that PR.

Add a new option to lock cells using an hash, as an intermediate between the global lock option and the subscriptions lock.

Using FlightsInSubs test, with 8 clusters, on a single-local CRDB node we can see an improvement others lock methods.

(Don't include option in terraform/helm/tanka yet)

[BenjaminPelletier]

I think we should check performance under conditions at least somewhat similar to real operations, which I think means at least multiple nodes, probably multiple instances, and latency between nodes. I first measured v0.22.0 with:

monitoring$ export NUM_USS=7
monitoring$ export NUM_NODES=3
monitoring$ export INTRA_USS_NETEM_CONF="delay 600us 40us 25% distribution normal loss 0.0005%"
monitoring$ export INTER_USS_NETEM_CONF="delay 36ms 40ms 50% distribution paretonormal loss 0.25% 15%"
monitoring$ make start-locally
monitoring$ AUTH_SPEC="DummyOAuth(http://localhost:8085/token,locust)" uv run --index https://pypi.org/simple locust -f ./monitoring/loadtest/locust_files/FlightsInSub.py -H http://localhost:8001 --uss-base-url http://testdummy.interuss.org/uss --cluster-count 11 --base-lat 34 --base-lng -118 --area-radius 15182 --max-flight-distance 10000

With 10 users, I got:

I then measured with this branch:

dss$ ./build/build.sh
dss$ docker image tag interuss-local/dss interuss/dss:v0.22.0
monitoring$ make down-locally
<edit monitoring/build/dev/startup/core_service.sh to specify -enable_scd_hash_lock>
monitoring$ make start-locally
monitoring$ AUTH_SPEC="DummyOAuth(http://localhost:8085/token,locust)" uv run --index https://pypi.org/simple locust -f ./monitoring/loadtest/locust_files/FlightsInSub.py -H http://localhost:8001 --uss-base-url http://testdummy.interuss.org/uss --cluster-count 11 --base-lat 34 --base-lng -118 --area-radius 15182 --max-flight-distance 10000

Just to make sure my retag worked:

monitoring$ docker container logs local_infra_1-1-dss-1 2>&1 | head -n 30
Using CockroachDB
Waiting for datastore db1.uss1.localutm:26257...
Datastore db1.uss1.localutm:26257 is not available yet, sleeping...
Datastore db1.uss1.localutm:26257 is not available yet, sleeping...
Datastore db1.uss1.localutm:26257 is not available yet, sleeping...
Datastore db1.uss1.localutm:26257 is not available yet, sleeping...
Datastore db1.uss1.localutm:26257 is not available yet, sleeping...
Datastore db1.uss1.localutm:26257 is online!
Debug Mode: off
2026-06-17T06:52:24.128Z	info	core-service/main.go:255	version	{"address": ":80", "version": "0.0.0+49c67230-dirty"}

I see some latency improvement versus v0.22.0 and a tiny throughput improvement, so looks reasonable to me. I will leave final approval to @barroco with his greater practical experience with database operations than me.

[barroco]

Still reviewing the results.

[barroco]

Thanks for the update - Will run some tests