Executor instead of ThreadFactory for DebeziumMP

[artembilan]

Related to #8642

For consistency with other Spring requirements and realignment with virtual threads, it is better to require a TaskExecutor injection instead of ThreadFactory

• Fix DebeziumMessageProducer to rely on a TaskExecutor API instead of ThreadFactory and ExecutorService

[tzolov]

Aren't you supposed to gracefully stop the task executor on exit?

[artembilan]

See a destroy() impl in the super class. It does call that stop(); for us.

[tzolov]

@artembilan,
iirc we picked the ThreadFactory initially, because we assumed that it will be easy to support virtual threads.
Is the TaskExecutor switch affecting this?

[artembilan]

Is the TaskExecutor switch affecting this?

As far as I know that's the move Spring Framework (provides a VirtualThreadTaskExecutor) and Spring Boot (will auto-configure that VirtualThreadTaskExecutor) expect from us.
Plus asking for TaskExecutor injection is really what we do in many other places. Therefore for consistency I switch this to the same style as it is everywhere else in Spring.
See also what we have discussed with Gary in the issue related to this change: #8642

Well, the PartitionedChannel is an exception since that one really requires a dedicated thread for particular partition.
I won't mind, though, to migrate that one to a TaskExecutor as well, if there is the way to stick to the specific thread.

[tzolov]

Ok, LGTM