[Improvement]: Extend OIDC token/userinfo claim handling: additional scopes, removable roles claim, configurable sub, and custom claims support #5063

Description

Thunder ID engine owns token issuance (token_endpoint) and claims assembly (userinfo_endpoint) for eSignet's OIDC flows. Following a discussion on evolving eSignet's openid-configuration (well-known), four related changes were identified that all require updates to Thunder's scope-to-claims mapping, since that's where these values are actually resolved and returned.

Current Limitation

• Scopes: Thunder supports a fixed set of scopes (profile, email, phone, roles) with no supported way to add a new scope and its underlying claim mapping without further code changes.
• Roles claim: The roles scope is currently always included, with no way to disable or remove it.
• sub claim: The subject identifier generation strategy is fixed (not configurable) — there is no option to switch between subject types (e.g., pairwise vs. public) or customize the generation algorithm per deployment.
• Custom claims: There is no general mechanism to include claims beyond the standard/fixed claim set in the ID token or userinfo response — the claim source/resolution layer only handles a hardcoded list.

Suggested Improvement

• Additional scopes: Add a configurable scope-to-claims mapping so new scopes can be introduced (and their underlying attributes resolved) without a code change per scope, mirroring the flexibility of eSignet's old mosip.esignet.openid.scope.claims config model.
• Removing roles: Make the roles claim inclusion configurable/removable — either via a config flag or by allowing it to be excluded from the scope-to-claims mapping.
• Configurable sub: Add a config option to select the subject identifier strategy (e.g., pairwise vs. public) and/or a pluggable generation algorithm, applied at token-issuance time.
• Custom claims: Extend the claim source/resolution layer to accept an arbitrary, config- or plugin-driven claim-to-attribute mapping, so deployments can expose claims beyond the standard OIDC set in the ID token and userinfo response.

Acceptance Criteria

• A new scope can be added via configuration and its mapped claims appear correctly in the ID token/userinfo response, without additional code changes.
• The roles claim can be disabled via configuration and no longer appears in the well-knowns response when not configured.
• The sub claim generation strategy can be switched via configuration (e.g., pairwise vs. public) and produces the expected value for each mode.
• A custom claim, configured via the new mechanism, should be used for filtering or identifying the supported claim set.
• Existing default behavior (current scopes, current roles behavior, current sub strategy) is preserved when no new configuration is set, to avoid breaking existing deployments.