chore: merge same events for kbagent

[ursasi]

1. Merge same events.
2. Eliminate unnecessary logs.

Current issues [solved]

Expectation

47s (x12 over 47s) => 47s (x12 over xxx not 47 s)
Should not be displayed as two identical times, because each time newEvent is executed.

Reason

1. Use EventTime.UnixMicro() of event as the version number in event_controller.go
2. Every time the event is updated, EventTime will be updated. This results in a new version number being generated with each update, rendering version checking ineffective.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 62.64%. Comparing base (33bb8c8) to head (0497a48).
Report is 31 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8445      +/-   ##
==========================================
+ Coverage   60.34%   62.64%   +2.30%     
==========================================
  Files         357      378      +21     
  Lines       42589    48004    +5415     
==========================================
+ Hits        25699    30073    +4374     
- Misses      14566    15335     +769     
- Partials     2324     2596     +272     

Flag	Coverage Δ
unittests	62.64% <100.00%> (+2.30%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zjx20]

I think the Get() call should be part of the retry logic. For example, the call may fail due to temporary network failures, retry can help in this case.

[zjx20]

I must say I prefer the previous implementation, which packages the get and create/update operations together as a single retry unit, rather than retrying them separately. Update conflicts are a common type of error in the Kubernetes world, and re-getting the latest version of the data and then updating is the standard pattern for resolving such issues.

[ursasi]

I must say I prefer the previous implementation, which packages the get and create/update operations together as a single retry unit, rather than retrying them separately. Update conflicts are a common type of error in the Kubernetes world, and re-getting the latest version of the data and then updating is the standard pattern for resolving such issues.

So actually, get and create or get and update should be considered as a retry unit, instead of retrying update or create operations separately.

[leon-inf]

The strategy by which kbagent sends events has changed, so the event handling should also be adjusted accordingly.

[ursasi]

The strategy by which kbagent sends events has changed, so the event handling should also be adjusted accordingly.

The code logic has been adjusted based on whether synchronous event sending is needed.

[leon-inf]

k8serrors -> apierrors

[leon-inf]

/cherry-pick release-1.0-beta

[github-actions]

🤖 says: cherry pick action finished successfully 🎉!
See: https://github.com/apecloud/kubeblocks/actions/runs/12114822536