Merged PR 2852: Fix: ensure priority selection on user migration

# Description

Fixing logic to ensure priority selection of claims when user satisfies multiple claim conditions.
It adds a new parameter that forcefully prioritises the selection of the date value for a certain claim over the others. If the value is repeated among claims, it will select the earliest date.

# Checklist

- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.

# Other

- [ ] Check if a full-refresh is required after this PR is merged.

Related work items: #20773

macros/user_migration_configuration.sql

@@ -18,6 +18,11 @@ Important note: if a user migrates once a phase has started, we
     It is likely that User B won't have Bookings from new dash
     until it's migrated. So this migration date should be considered
     as a hard, lower-limit of dates.
+
+    If a user satisfies more than one valid claims, in order to ensure 
+    that the good date is considered we use the claim_enforcement_priority 
+    value to force that a certain claim type will have precedence over
+    another. The lower the value, the more priority.
 */
 {% macro get_new_dash_migration_phases_config() %}
     {% set migration_phases = [
@@ -25,11 +30,13 @@ Important note: if a user migrates once a phase has started, we
             "phase_name": "MVP",
             "claim_type": "KYGMVP",
             "default_deployment_date": "2024-07-30",
+            "claim_enforcement_priority": 1,
         },
         {
             "phase_name": "MVP",
             "claim_type": "MVPMIGRATEDUSER",
             "default_deployment_date": "2024-09-10",
+            "claim_enforcement_priority": 0,
         },
     ] %}
     {{ return(migration_phases) }}

models/intermediate/core/int_core__user_migration.sql

@@ -36,7 +36,14 @@ with
                     then date('{{ phase.default_deployment_date }}')
                 {% endfor %}
                 else null
-            end as lower_limit_migration_date_utc
+            end as lower_limit_migration_date_utc,
+            case
+                {% for phase in migration_phases %}
+                    when upper(claim_type) = '{{ phase.claim_type }}'
+                    then '{{ phase.claim_enforcement_priority }}'
+                {% endfor %}
+                else null
+            end as claim_enforcement_priority
         from stg_core__claim
         where
             {% for phase in migration_phases %}
@@ -45,17 +52,26 @@ with
             {% endfor %}
 
     )
--- Get only the first time the user was migrated, among different claim types that
+-- Get only one migration date per user migrated. If a user satisfies several claims,
--- satisfy the user migration possibility
+-- the date corresponding to the claim with more priority will be selected. The lower
-select id_user_host, migration_phase, lower_limit_migration_date_utc
+-- the claim_enforcement_priority, the more priority it will have. If still 2 claims
+-- have the same priority, select the earliest date.
+select
+    id_user_host,
+    migration_phase,
+    lower_limit_migration_date_utc,
+    claim_enforcement_priority
 from
     (
         select
             id_user_host,
             migration_phase,
             lower_limit_migration_date_utc,
+            claim_enforcement_priority,
             row_number() over (
-                partition by id_user_host order by lower_limit_migration_date_utc asc
+                partition by id_user_host
+                order by
+                    claim_enforcement_priority asc, lower_limit_migration_date_utc asc
             ) as rank
         from user_migration_from_claim
     )