DPL: give each stream its own slot in the service registry

The registry derives a service's slot from the low 8 bits of
type.hash ^ valueFromSalt(salt), but valueFromSalt puts the streamId at bit 16,
so every stream lands on the same slot for a given service and fills up the
same MAX_DISTANCE-deep probe window -- after which registration is refused,
blaming whichever service lost the race rather than the one which filled the
window. Mix the salt into the low bits instead: only the starting slot changes
(valueFromSalt still carries key equality, and both getPos and registerService
go through instanceFromTypeSalt), and unlike widening the table this raises no
new ceiling. With DPL_THREADPOOL_SIZE=4, o2-test-framework-SimpleDataProcessingDevice01
goes from 0/20 runs passing to 14/20, and 17/20 at 8 streams where 9 entries
could not previously share a window of 8 at all.

Author: ktf

Framework/Core/include/Framework/ServiceRegistry.h

@@ -177,7 +177,18 @@ struct ServiceRegistry {
 
   constexpr InstanceId instanceFromTypeSalt(ServiceTypeHash type, Salt salt) const
   {
-    return InstanceId{type.hash ^ valueFromSalt(salt)};
+    // Fold the whole salt down into the low bits. The slot is the low bits of
+    // this (see indexFromInstance) while streamId sits at bit 16 of
+    // valueFromSalt, so using that directly gives every stream the same slot
+    // for a given service: they pile into one probe window, and once it is
+    // MAX_DISTANCE deep the next registration is refused -- reported against
+    // whichever service happened to lose, not the one which filled it.
+    //
+    // Widening the table does not help on its own: the mask stays below bit 16
+    // until MAX_SERVICES passes 65536.
+    uint32_t mixed = static_cast<uint32_t>(static_cast<uint16_t>(salt.streamId)) * 0x9E3779B9u ^
+                     static_cast<uint32_t>(static_cast<uint16_t>(salt.dataProcessorId));
+    return InstanceId{type.hash ^ mixed};
   }
 
   constexpr Index indexFromInstance(InstanceId id) const