Improve docs for Hibernate ORM with Kafka to suggest more efficient approaches

[LarsSven]

The context of this PR is the following discussion: #45792

Basically, we have a REST endpoint in our product using Quarkus that uses Hibernate and Kafka message sending. We switched this over from Hibernate Reactive to Hibernate ORM (and therefore got rid of the mutiny stack), and noticed a significant slowdown in throughput that was unrelated to switching away from Mutiny. After some investigations and discussions, we noticed that the performance regression was inherent to how Quarkus suggests you use Hibernate ORM with Emitters, which is suboptimal.

The big thing that happens with the suggested approach is that due to returning an asynchronous call of the message emitter to a function using @Transactional, all Hibernate transaction commits happen from the asynchronous thread, which makes all transactions commit on the same thread, which obviously causes a slowdown in throughput.

This PR tries to change 2 things about the suggested approach by the documentation:

1. (less important): Always use the MutinyEmitter since it is more optimised according to @cescoffier: "The MutinyEmitter is way more optimized and should be the standard choice" (Performance regression when using Hibernate with reactive message queues #45792 (reply in thread))
2. (more important): Do not commit the transaction in async space.

I would personally say this documentation is definitely still a bit rough. It is an initial suggestion that I maybe can iterate on based on feedback. Some of the things I'm already wondering with this change:

1. Should we use MutinyEmitter for both examples since it should be standard, or should we still show the normal Emitter in the second approach.
2. What is a right balance between the length of the documentation and the number of options covered? Of course there is also for example a MutinyEmitter async approach, and an Emitter sync approach
3. Should the reasons for going with approach one be an itimized list or numbered list
4. More general things: Is the structure good?

Essentially, I look forward to feedback and whether you agree with this documentation change.

[ozangunalp]

I think we need to completely replace the CompletionStage example by the sendAndAwait one.

[LarsSven]

@ozangunalp I reduced the change to just editing the example. Of course the text around it then makes no more sense so I still had to make changes there, let me know if you agree with them.

[github-actions]

🙈 The PR is closed and the preview is expired.

[cescoffier]

Can you squash your commits ?

[LarsSven]

@ozangunalp I just saw you pushed to the branch. Should I still squash the branch?

[ozangunalp]

@LarsSven I just rebased it. It'd be great if you can squash + repush, Thanks

[LarsSven]

I squashed them @ozangunalp

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 4e83ba9.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.