Procedural constraints annotation processor + build logic

[skovati]

• Tickets addressed: closes Annotation Processor updates for Procedural Constraints #1571
• Review: By commit
• Merge strategy: Merge (no squash)

Description

Luke to fill out

Verification

Documentation

Future work

[Mythicaeda]

This PR is currently orphaned, pair programming hosted by @mattdailis prior to handoff.

This PR has compiled a constraint w/o arguments, so it's potentially close.

@JoelCourtney to add example constraints to this branch

Decision to be made: support non-records or updating docs? @JoelCourtney proposing to just update docs and allow non-records later.

Let's start with only records and double-back for non-record support.

[JoelCourtney]

State of PR:

The annotation processor worked without any extra work. It was actually so good at combining the scheduling / constraints workflows that the gradle task can't tell them apart, and the original buildAllSchedulingProcedureJars task would build the constraints as well. So I've just removed the Scheduling, making it buildAllProcedureJars. I don't see why the user would need separate workflows for them anyway. The annotation processor does still generate different value mapper types for goals & constraints. Since this gives us a bit of type safety during procedure loading, I figured I'd leave it and not combine them. So:

• two different annotations
• one annotation processor
• two value mappers
• one gradle command

I haven't made the equivalent of the scheduler's Procedure.java for constraints. I'm not sure that's included in this task, but I can work on it because it seems like the logical next step.

[sonarqubecloud]

Quality Gate failed

Failed conditions
9.2% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud