Split CI/CD-related infrastructure into its own model

[dogboat]

Description

This PR splits CI/CD-related infrastructure (scm/build/orchestration servers) out of the Tool_Configuration model into its own CICDInfrastructure model. Engagements are updated with new fields to point to the new model; the old fields are dropped.

The migration creates CICDInfrastructure objects from existing Tool_Configuration models used by engagements and populates the new fields on each engagement accordingly.

[sc-12921]

[valentijnscholten]

This looks OK at first sight. Some thoughts:

• dojo/models.py also contains some logic around scm_type, mainly to construct urls to commits. Should this be harmonized/included here as well? Maybe in a follow-up PR?
• The engagement API changes should probably be mentioned in the upgrade notes. According to Mr Claude:

Breaking API change: Engagement cicd server fields

EngagementSerializer uses exclude = ("inherited_tags",), so it auto-reflects model fields. This PR removes the old engagement FKs and adds new ones, changing the Engagement payload in a backward-incompatible way:

Before	After
build_server	cicd_build_server
source_code_management_server	cicd_scm_server
orchestration_engine	cicd_orchestration_engine

Three things break for existing clients:

• Field names renamed → old keys rejected as unknown / absent on read.
• Target model changed: values were Tool_Configuration IDs, now CICDInfrastructure IDs — same integer, different object. A client that hardcoded a tool-config ID now points at the wrong row or a non-existent one.
• Validation: new FKs use limit_choices_to={"infrastructure_type": ...}, so posting a cicd_build_server ID whose type isn't build_server is rejected — a new constraint that didn't exist before.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[mtesauro]

Approved

[dogboat]

This looks OK at first sight. Some thoughts:

* `dojo/models.py` also contains some logic around `scm_type`, mainly to construct urls to commits. Should this be harmonized/included here as well? Maybe in a follow-up PR?

* The `engagement` API changes should probably be mentioned in the upgrade notes. According to Mr Claude:

Breaking API change: Engagement cicd server fields

EngagementSerializer uses exclude = ("inherited_tags",), so it auto-reflects model fields. This PR removes the old engagement FKs and adds new ones, changing the Engagement payload in a backward-incompatible way:
Before After
build_server cicd_build_server
source_code_management_server cicd_scm_server
orchestration_engine cicd_orchestration_engine

Three things break for existing clients:

* **Field names** renamed → old keys rejected as unknown / absent on read.

* **Target model** changed: values were `Tool_Configuration` IDs, now `CICDInfrastructure` IDs — same integer, different object. A client that hardcoded a tool-config ID now points at the wrong row or a non-existent one.

* **Validation**: new FKs use `limit_choices_to={"infrastructure_type": ...}`, so posting a `cicd_build_server` ID whose type isn't `build_server` is rejected — a new constraint that didn't exist before.

Hey, thanks for keeping this alive, and really sorry, I got sidetracked! Really appreciate you not giving up on me tho. ;-)

OK, I confirmed with @mtesauro that the breaking changes you listed are acceptable, though if you want to push back on any of them please do. Part of the goal for this change was to throw some guardrails up around the way the CI/CD infrastructure was used, and it does break things, but in a way considered good. But yeah, great point to the need for upgrade notes, and I'll flag the scm_type URL construction for followup.