Emit Kubernetes events from the operator controllers

[HoustonPutman]

Closes #120

Fills in the // TODO: Create event markers and adds event recording across the SolrCloud, SolrPrometheusExporter, and SolrBackup controllers (config validation, scheduled restarts, cluster operations, replica migration, PVC expansion, scaling, and backup lifecycle).

Also grants the operator RBAC to create events — without it the broadcaster silently dropped every event, so the previously merged PVC-expansion events never persisted either.

Adds a no-op EventRecorder so reconcilers call the recorder unconditionally, and wires recorders for the exporter and backup controllers.

Tested at three layers: unit (FakeRecorder), envtest reconcile, and e2e (backups, scaling, rolling upgrades).

A lot of work done by Claude on this.

[janhoy]

Cool, so this means that if you monitor kube events, you won't have to go into the solrOperator logs to see what operations were done or failed anymore?

I cannot contribute with much more than clicking the "Copilot" review button right now :)

[Copilot]

Pull request overview

This PR adds Kubernetes Event emission across the Solr Operator controllers so users can see reconciliation progress and failures via kubectl describe, and updates RBAC so the operator is allowed to create/patch Events.

Changes:

• Wire record.EventRecorder into the SolrCloud, SolrPrometheusExporter, and SolrBackup reconcilers (with a no-op default) and emit events for key lifecycle/validation/cluster-operation paths.
• Grant RBAC permissions for events (create, patch) in both the generated manifests and Helm chart.
• Extend unit/envtest/e2e coverage to assert that expected events are recorded during scaling, rolling upgrades, and backups.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/e2e/solrcloud_scaling_test.go	Asserts scale up/down event reasons are emitted.
tests/e2e/solrcloud_rolling_upgrade_test.go	Asserts rolling upgrade cluster-operation events are emitted.
tests/e2e/resource_utils_test.go	Adds an e2e helper to wait for an Event to appear.
tests/e2e/backups_test.go	Asserts backup lifecycle/reschedule events are emitted.
main.go	Wires controller-runtime event recorders into reconcilers.
helm/solr-operator/templates/role.yaml	Adds Events RBAC to the Helm role/clusterrole.
controllers/util/solr_update_util.go	Emits replica migration events during eviction workflows.
controllers/suite_test.go	Wires recorders for envtest manager reconcilers.
controllers/solrprometheusexporter_controller.go	Adds recorder + emits config validation and restart scheduling events.
controllers/solrcloud_controller.go	Adds recorder + emits config validation, scheduling, and cluster-op events.
controllers/solrbackup_controller.go	Adds recorder + emits backup lifecycle/scheduling/error events.
controllers/solr_pod_lifecycle_util.go	Emits pod update/readiness-condition failure events.
controllers/solr_cluster_ops_util.go	Emits PVC expansion/scaling/cluster-state error events and removes nil-recorder guards.
controllers/reconcile_events_test.go	Adds envtest specs asserting events are produced by controllers.
controllers/events_test.go	Adds unit tests validating specific event emission paths with FakeRecorder.
controllers/event_recorder.go	Introduces a no-op EventRecorder implementation.
config/rbac/role.yaml	Adds Events RBAC to generated ClusterRole.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[HoustonPutman]

Cool, so this means that if you monitor kube events, you won't have to go into the solrOperator logs to see what operations were done or failed anymore?

Yeah, a lot of information can be populated there. Errors plus operational things like restarting pods, backups, etc. So the logs should be purely for debugging now!

[HoustonPutman]

I cannot contribute with much more than clicking the "Copilot" review button right now :)

Looks like co-pilot likes it. Luckily this is pretty low-risk since we are just adding events in addition to existing logging, and the e2e tests make sure that it doesn't affect runtime.