Implement sending POJOs not within the Response to Events #3209
Description
Is your feature request related to a problem? Please describe.
Not a problem, but it would be nice to be able to add more information to events which are not currently returned to users. For example, in #3195, we are unable to send LoadTableResponses in the AfterTableUpdateEvent (which make sense for table updates to tell what is the current state of the table) in the case of a CommitTransaction. Meanwhile, if a user calls the UpdateTable API directly, they will still get the LoadTableResponse as part of the AfterTableUpdateEvent.
This is solely due to the way we have implemented events through the delegator model where intermediate information, which is not surfaced to the user as part of the API response, cannot be used in the event emission. There are other potential uses cases, such as telling whether a credential generated was a read or read+write credential when loading a table - which would also be interesting for auditing purposes.
Describe the solution you'd like
A clear mechanism is implemented where intermediary information can be resurfaced to the Events emission.
Describe alternatives you've considered
- [Not recommended] Overstuff the response body with all relevant information and then filter out only the IRC spec-required information before returning back to the user in the Delegator.
- Using Container Request Context to store intermediate information during the call processing, then retrieve the information whenever event emission is happening.
a. Unsure if this is wise, since most tests are not running with Container Request Contexts - and I'm unsure if inserting Quarkus mechanism within Iceberg business logic is a great idea. But maybe something to think about...
Additional context
No response