Backport: v4-migrator: Dedup PROJECT_PROPERTY rows of collapsed projects - #7360

…dencyTrack#7171)

* Dedup PROJECT_PROPERTY rows of collapsed projects in v4-migrator

The §4.8 PROJECT collapse rewrites PROJECT_ID through
project_canonical_id_map, so two projects that were distinct in v4 can end
up sharing a canonical PROJECT_ID. Two PROJECT_PROPERTY rows that were
distinct in v4 by virtue of their PROJECT_ID then become the same
(PROJECT_ID, GROUPNAME, PROPERTYNAME) triple, and the load fails with:

  duplicate key value violates unique constraint "PROJECT_PROPERTY_KEYS_IDX"

Other tables affected by a collapse already handle this: MAPPEDLDAPGROUP
uses DISTINCT ON to keep MIN(ID) after the team collapse, and the
PROJECT-keyed join tables rely on ON CONFLICT DO NOTHING. PROJECT_PROPERTY
was missed.

Apply the same DISTINCT ON treatment, keeping MIN(ID) to match the
canonical-ID convention and to keep reruns deterministic.

Fixes DependencyTrack#7114

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>

* Keep the surviving project's own property value on collapse

The PROJECT collapse keeps the newest project, so preferring MIN(ID) here
handed the survivor a property value belonging to a project the migrator had
just decided to discard. The test asserted that wrong outcome too.

Prefer the row that belonged to the surviving project. Where only discarded
projects carried the property, the lowest ID still wins, to keep reruns
deterministic.

Fold the case into PropertyTablesIT, which already covers PROJECT_PROPERTY,
and add a RowCountNotes entry so the differing row count has an explanation.

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>

---------

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>
(cherry picked from commit a1f50b2)
Signed-off-by: nscuro <nscuro@protonmail.com>