Fix duplicate RUNNING_VM helper record creation on repeated VM.START events

[SURYAS1306]

Description

Repeated VM.START events for the same VM could result in duplicate
RUNNING_VM helper usage records being created in the usage database.

This PR adds a defensive check in UsageManagerImpl#createVMHelperEvent
to detect an existing active RUNNING_VM usage record (same VM instance,
endDate = NULL) and skip helper record creation when a duplicate START
event is received.

A regression test has been added to ensure that duplicate RUNNING_VM
helper records are not created when repeated VM.START events are
processed.

Fixes: #12590

Expected behavior

Only one active RUNNING_VM usage helper record should exist per VM at
any given time.

Actual behavior

Multiple RUNNING_VM helper records could be created for the same VM
when duplicate VM.START events were processed.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Test (unit or integration test code)

Bug Severity

• Minor

How Has This Been Tested?

• Added a unit test in UsageManagerImplTest to verify that duplicate
  RUNNING_VM helper records are not created when repeated VM.START
  events are handled.
• Built and tested the cloud-usage module successfully using Maven.

How did you try to break this feature and the system with this change?

• Simulated repeated VM.START events for the same VM instance to ensure
  that helper record creation is skipped when an active RUNNING_VM
  record already exists.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache CloudStack community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
Here are some useful points:

• In case of a new feature add useful documentation (raise doc PR at https://github.com/apache/cloudstack-documentation)
• Be patient and persistent. It might take some time to get a review or get the final approval from the committers.
• Pay attention to the quality of your code, ensure tests are passing and your PR doesn't have conflicts.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Issues, Mailing list and Slack.
• Be sure to read the CloudStack Coding Conventions.
  Apache CloudStack is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@cloudstack.apache.org (https://cloudstack.apache.org/mailing-lists.html)
  Slack: https://apachecloudstack.slack.com/

[DaanHoogland]

Thank you @SURYAS1306 , can you rebase this on the 4.20 branch?

[abh1sar]

Thanks for working on this @SURYAS1306 .
But skipping insertion into the usage_vm_instance table is not the right approach.

id	type	account_id	created	count	resource_id	name
106	VM.START	6	2025-10-27 13:02:07	2	200	fedora
107	VM.STOP	6	2025-10-27 13:02:06	2	200	fedora
108	VM.START	6	2025-10-27 13:02:07	2	200	fedora

In the example above, if we skip the last event, it will cause usage to never register the Instance as started and it will not be billed properly.

[SURYAS1306]

Thanks for the review.

That makes sense skipping the helper record creation could indeed cause the VM state to be inconsistent and affect billing.

I'll revisit the approach and focus on handling duplicate VM.START events in a way that keeps the usage state correct (likely by making the processing idempotent rather than skipping the event).

I'll rework the fix and update the PR.

[abh1sar]

Thanks for the review.

That makes sense skipping the helper record creation could indeed cause the VM state to be inconsistent and affect billing.

I'll revisit the approach and focus on handling duplicate VM.START events in a way that keeps the usage state correct (likely by making the processing idempotent rather than skipping the event).

I'll rework the fix and update the PR.

Thanks, can you turn the PR into Draft until then?