Add logging of service metadata during instance create/update/delete

[kathap]

Inform operators which service plan, service offering and broker is involved in service instance creation/update/deletion

• A short explanation of the proposed change:
  Add names of service plan, service offering and broker as logging information for service instance creation/update/deletion.
  This change updates fetch_writable_service_instance to eagerly load associated service_plan, service, and service_broker relationships for managed service instances. This avoids N+1 queries when accessing these associations later in the request lifecycle.

• An explanation of the use cases your change solves
  This change improves operator visibility by logging service plan names, offerings, and broker names during service instance creation, update, and deletion.
  Previously, logs only included GUIDs or IDs, requiring manual lookups or customer input to identify the service involved. With this change, operators can directly see which service is affected, making it easier to diagnose issues and support users/customers more efficiently.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[philippthun]

When I tested this, a database query to fetch broker information was executed.

It seems as if service_instance.reload (here) removes the associated objects (or at least some of them).

So for the update_managed part, eager loading does not have the expected benefits.

Additional question: can the service plan be updated? This would even make the eager loading completely obsolete in such a case.

[kathap]

The service plan can be updated, yes.

[svkrieger]

Good catch with the reload! I removed the reload now and use a copy of the service instance instead for verifying the updated object, to ensure that follow-up preflight checks run with the original service instance object.

To your question: Yes, the plan is updatable. But only for the same service offering -> so eager loading the service and broker still provides a benefit because those will never change for a service instance.

I compared the number of DB queries in main with the ones from this PR:

Scenario/codebase	main	PR
create	73	71
update	95	91
delete	48	48

-> even though we are fetching more information for the logs, this will reduce the number of queries for create/update cases and stays the same for the delete case.