refactor(rental): extract duplicated Zeebe variable-setting into a shared utility

[devin-ai-integration]

Summary

The rental-service job workers each repeated the same Zeebe boilerplate to write process variables and to trigger BPMN compensation. The chain

zeebeClient.newSetVariablesCommand(job.getProcessInstanceKey())
    .variables(Map.of(key, value))
    .send()
    .join();

appeared ~9 times across BankWorker, RentalWorker, StationWorker, FleetManagementWorker, and the compensate pattern (set failureReason then throw new ZeebeBpmnError("COMPENSATE_AND_NOTIFY", msg)) was duplicated in BankWorker and VehicleWorker. The "COMPENSATE_AND_NOTIFY" / "failureReason" strings were also hard-coded in multiple places.

This PR consolidates all of it into one shared helper com.acme.rental.util.zeebe.ZeebeProcessVariables:

ZeebeProcessVariables.set(zeebeClient, job, "rentalStartTime", value);   // single var
ZeebeProcessVariables.set(zeebeClient, job, map);                        // multiple
ZeebeProcessVariables.set(zeebeClient, processInstanceKey, map);         // by key
ZeebeProcessVariables.failAndCompensate(zeebeClient, job, reason);       // set failureReason + throw ZeebeBpmnError

The magic strings become ZeebeProcessVariables.COMPENSATE_AND_NOTIFY_ERROR and FAILURE_REASON_VARIABLE.

Callers were updated to delegate:

• The four workers now call ZeebeProcessVariables.set(...) instead of inlining the command chain, and BankWorker/VehicleWorker use failAndCompensate(...).
• The existing CamundaProcessVariablesWriter.setVariables(...) now delegates to ZeebeProcessVariables.set(...) so there is a single implementation of the command chain.

Behavior is unchanged — the helper is a static method that operates on the worker's own ZeebeClient, so the existing unit tests (which mock the newSetVariablesCommand(...) chain) continue to pass without modification.

Notes / out of scope

There is also cross-module duplication (e.g. identical WebCorsConfig and the station operation DTOs between rental-service and stations-service). I intentionally left those alone: the services are independent Maven modules and sharing code across them would introduce a coupling/shared-module decision better made explicitly. Happy to tackle it in a follow-up if desired.

Testing

• mvn test in acme-mobility/rental-service: 63 passed, 0 failures.

Link to Devin session: https://app.devin.ai/sessions/d6b9330112b149c1962ad4431539425c
Requested by: @NicolasCola7

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring