[wolf4ood]

What this PR changes/adds

Makes (participantContextId, id) the identity of a DataPlaneInstance, as decided in the follow-up of the
per-participant resource identifiers
decision record.

• Stores.

  • SQL: participant_context_id is NOT NULL, the primary key is (participant_context_id, id), and the upsert
    conflicts on that pair. The participant_context_id index is dropped from the schema: the primary key covers it.
  • In-memory: instances are keyed by ParticipantResourceKey.

• SPIs (breaking).

  SPI	before	after
  DataPlaneInstanceStore	findById(id), deleteById(id), getAll()	findById(participantContextId, id), deleteById(participantContextId, id)
  DataPlaneSelectorService	findById(id), delete(id), unregister(id), getAll()	findById(participantContextId, id), delete(participantContextId, id), unregister(participantContextId, id)

  save/register, query/search and selectFor keep their signatures.

• Callers.

  • DataPlaneSignalingFlowController and DataPlaneTransferAuthorizationFilter take the participant context of the
    transfer process.
  • The v4 registration delete and the v4 GET /v4/dataplanes take the participant context of the
    SingleParticipantContextSupplier. The listing now returns only the instances of that participant context.
  • The v5 registration and delete use the participant context of the path. The cross-tenant check that answered 409
    is removed: the same id can now be registered by different participant contexts.

• Migration. New README.md in data-plane-instance-store-sql, with the statements to migrate an existing
  database. Rows with a NULL participant context must be assigned to one first.

Why it does that

With global ids, the v5 registration revealed the ids used by other participant contexts (409) and allowed squatting
them, and the store and service SPIs could be called without any participant context (M9 follow-up and L3 in #6005).

Further notes

• Breaking for custom DataPlaneInstanceStore and DataPlaneSelectorService implementations and for their callers.
• Migrating an existing SQL database requires the deployer to apply the documented UPDATE / ALTER TABLE
  statements.
• Tested with the store contract tests (in-memory and PostgreSQL), the unit and API tests of the touched modules, and
  the data plane registration, data plane selector and catalog end-to-end tests (in-memory and PostgreSQL).

Who will sponsor this feature?

Please @-mention the committer that will sponsor your feature.

Linked Issue(s)

Part of #6005

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.