fix: segments/logs lost when two processes first report for the same service concurrently

[wu-sheng]

Problem

SegmentItems.addSegmentItem and LogItems.addLogItem do a check-then-act on the map:

SegmentItem segmentItem = segmentItems.get(serviceName);
if (segmentItem == null) {
    segmentItem = new SegmentItem(serviceName);
    segmentItems.put(serviceName, segmentItem);   // not atomic with the get
}
segmentItem.addSegments(segment);

When two agent processes report their first data for the same service name concurrently, both handler threads see null, both create an item, and the second put overwrites the first — the data appended to the discarded item is silently lost while both reporters receive HTTP 200.
Only the first insert per service name is affected: SegmentItem/LogItem hold a CopyOnWriteArrayList, so appends are safe once the key exists. The map is a ConcurrentHashMap, so the intent was clearly thread-safety — the get/put pair just defeats it. Every receiver funnels into these methods (gRPC and both HTTP servlets), so the loss is transport-independent.

Impact

Found while debugging a flaky test in apache/skywalking-python#409: a plugin test forks a worker, so parent and child share one service name and post their first segments milliseconds apart. A segment disappeared in roughly 2 of 5 CI runs — sometimes the parent's, sometimes the child's — which looked like an agent bug for quite a while.
Reproduced directly against this collector image, from inside its network:

scenario	result
200 rounds of two barrier-synchronized first-time POSTs per fresh service name	15/200 rounds silently lost a segment (segmentSize=1)
same 200 rounds, key pre-seeded by one sequential POST first	0/200 lost
Tests where each process uses a distinct service name (the common case) are unaffected, which is why this stayed hidden.

Fix

Use computeIfAbsent, which performs the get-or-create atomically — the pattern MeterItems.addMeter already uses in this same package:

final SegmentItem segmentItem = segmentItems.computeIfAbsent(serviceName, SegmentItem::new);
segmentItem.addSegments(segment);

Once a new image is published, the workaround in apache/skywalking-python#409 (seeding the service name with a warm-up request before the concurrent pair) can be removed.

Also: repair the macOS CI job

CI-on-MacOS has been failing since GitHub moved macos-latest to arm64 — unrelated to this change, but it blocks every PR. With actions/setup-java@v1, JAVA_HOME points at a hosted-toolcache path lacking the macOS Contents/Home layout, so $JAVA_HOME/bin/java does not exist and mvnw aborts with JAVA_HOME is not defined correctly before compiling anything (the log hands out an x64 JDK 8 path on an arm64 runner). setup-java@v1 also runs on a Node runtime GitHub has already removed.
Both jobs move to actions/setup-java@v4 and actions/checkout@v4. The distribution must be zulu, not temurin: JDK 8 has no macOS aarch64 temurin build, while zulu publishes one. Both actions are in the actions/* namespace, which the ASF allow-list permits without a SHA pin.

Verification

Java 8 remains the build JDK — ./mvnw -pl mock-collector -am compile passes under Zulu 8 locally (BUILD SUCCESS), and both CI jobs are green on this PR.