[OB3] Consents with duplicate attribute values doesn't expire

[imesh94]

When there are more than one consent attributes with the same value for a consent, that consent is not expired when the consent expiration job is run. (This issue might cause failures in other flows as well where consent search is used).

How to reproduce:

1. Create a consent with short expiration time. Par/authorize request should contain multiple claims with the same value:

"claims": {
    "id_token": {},
    "userinfo": {}
  }

2. Wait for the consent expiration job to run.

3. Note that the consent is not expired.

Root cause:

• We have used consent search to get the consents eligible for expiration.
  https://github.com/wso2/financial-services-accelerator/blob/3.0.0/open-banking-accelerator/components/consent-management/com.wso2.openbanking.accelerator.consent.mgt.dao/src/main/java/com/wso2/openbanking/accelerator/consent/mgt/dao/impl/ConsentCoreDAOImpl.java#L1927

• In consent search query, we have used the 'distinct' keyword when retrieving consent attributes to avoid duplicates. (Current query causes each consent attribute to duplicate).
  https://github.com/wso2/financial-services-accelerator/blob/3.0.0/open-banking-accelerator/components/consent-management/com.wso2.openbanking.accelerator.consent.mgt.dao/src/main/java/com/wso2/openbanking/accelerator/consent/mgt/dao/queries/ConsentMgtCommonDBQueries.java#L168

• Due to duplicates being removed, the number of Attributes keys and attribute values differ.
  https://github.com/wso2/financial-services-accelerator/blob/3.0.0/open-banking-accelerator/components/consent-management/com.wso2.openbanking.accelerator.consent.mgt.dao/src/main/java/com/wso2/openbanking/accelerator/consent/mgt/dao/impl/ConsentCoreDAOImpl.java#L1653

• Consent attributes are not retrieved in the consent search response due to this.

Solutions:

1. Introduce a new method to get consents eligible for expiration.

   This can be done since we only use consentIDs to get the eligible consents for expiration. A complex query like consent search is not required for this scenario.

2. Remove 'distinct' keyword from the search query.

   This seems safe because duplicates values caused by the query are anyway handled when adding consent attributes to the consentAttributesMap. But we have to check all the usages of the query.

3. Modify the consent search query to avoid duplicating consent attributes.

   Might consume more time to implement than other solutions, and we have to check all the usages of the query.