[Tharaka-Chathuranga]

Issue # (if applicable)

Closes #29851.

Reason for this change

UserPoolIdentityProviderOidc only accepts the client secret as a plain string, so there's no way to pass it in as a SecretValue (e.g. from Secrets Manager) like you can with the Google and Apple providers.

Description of changes

• Added clientSecretValue?: SecretValue to UserPoolIdentityProviderOidcProps.
• Made clientSecret optional and deprecated it in favour of clientSecretValue. Existing code that passes clientSecret keeps working and produces the same template.
• Exactly one of clientSecret / clientSecretValue has to be set, otherwise a ValidationError is thrown. I reused the ExactlyOneClientSecretClient error code from the Google provider since it's the same problem.
• Added an example to the README.

This follows the same approach as #22885 (Google) and #31409 (Apple). Two small differences from those:

• The check uses === undefined instead of truthiness so token values aren't treated as missing.
• The error message is lowercase without a trailing period to match the current error message guidelines. Happy to make it match the Google/Apple wording exactly if you'd rather keep them consistent.

Describe any new or updated permissions being added

None.

Description of how you validated changes

• Unit tests: added tests for clientSecretValue (Secrets Manager reference ends up in ProviderDetails.client_secret), for setting both props, and for setting neither. Moved the existing tests over to clientSecretValue and kept a testDeprecated test for the old clientSecret prop.
• Integ test: added a second OIDC provider to integ.user-pool-idp.oidc that reads its client secret from a Secret created in the stack. The existing provider's resources are unchanged. Snapshot was updated with --dry-run, I haven't deployed it.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license