Add support for configurable external badge issuance restrictions #3011

Description

Credentials should support an optional mechanism to evaluate whether a badge can be issued based on externally managed business rules.

Today, when a learner completes the requirements for a badge, issuance proceeds immediately. Some deployments need an additional validation step before issuing a badge, where an external service can determine whether badge issuance is allowed for the specific course context associated with the learner’s fulfillment.

This functionality should be optional, configuration-driven, and disabled by default so it does not change behavior for deployments that do not need it.

Business need

Some Open edX deployments need badge issuance to depend on business rules that are managed outside of Credentials.

Without this capability:

badge issuance may occur even when an external system considers it disallowed
operators must rely on manual processes or post-issuance cleanup
integrations cannot enforce business-specific rules at the point of badge issuance
Providing a configurable restriction check allows deployments to integrate Credentials with external decision-making systems while preserving the current default behavior for the broader community.

Acceptance criteria

• Operators can enable or disable badge issuance restriction checks through settings.
• The restriction check is optional and disabled by default.
• When enabled, Credentials evaluates badge issuance before issuing a badge.
• The restriction check uses the course context associated with the learner’s fulfillment.
• Credentials can query a configurable external API to determine whether issuance is allowed.
• If the external response indicates issuance is not allowed, the badge is not issued.
• If the feature is disabled, badge issuance behaves exactly as it does today.
• If no matching restriction data is returned, issuance is allowed by default.
• The feature is documented, including required settings and expected behavior.

Definition of done

• Backend implementation is complete.
• The implementation is covered by tests.
• Documentation is included in the PR.
• New settings and configuration expectations are documented.
• Default behavior remains unchanged when the feature is not enabled.

Additional context

A implementation has been proposed in: #3007