Add Spring Pulsar transaction support

[onobc]

Adds auto-config for Spring for Apache Pulsar transactions.

Introduces new txn config props for template and listener under the spring.pulsar.template.transaction and
spring.pulsar.listener.transaction prefixes, respectively.

Disables transaction support by default (opt-in feature).

Note

I still need to update/add docs for this but wanted to get this front-loaded as I will be out of pocket at DevNexus this week.

TODO

• Update ref docs w/ info about transaction support

[wilkinsona]

I've rebased, squashed, and polished the changes. While doing so, I had a bit more time to think about the .enabled and .required properties that can be configured in a way that's invalid. I still don't like it, I'm afraid.

With the .enabled and .required properties, it feels like one configuration option has been split across two settings.

I wonder if we could have a single property backed by an enum instead. The enum's values, something like DISABLED, SUPPORTS, and REQUIRES, would map to the current properties like this:

	.enabled	.required
DISABLED	false	false
SUPPORTS	true	false
REQUIRES	true	true
	false	true

With no value for the invalid .enabled=false .required=true combination, we've hopefully made things easier to configure.

I wonder if Spring Pulsar would also benefit from such a change as it too has enabled and required properties. If so, it could then also provide the enum that Boot exposes as a configuration property.

[onobc]

properties that can be configured in a way that's invalid. I still don't like it, I'm afraid.

Not a problem. Thanks for the focus on this. This is the perfect time to get it right (before people start using it).

With the .enabled and .required properties, it feels like one configuration option has been split across two settings.

Agreed.

I wonder if we could have a single property backed by an enum instead. The enum's values, something like DISABLED, SUPPORTS, and REQUIRES, would map to the current properties like this:

I like this approach.

With the .enabled and .required properties, it feels like one configuration option has been split across two settings.

Absolutely.

Based on the fact that we will want the enum to exist in Spring Pulsar and it has already cut the RC1 release, are you ok if we get this in during RC phase (like early next week) ?

[philwebb]

Based on the fact that we will want the enum to exist in Spring Pulsar and it has already cut the RC1 release, are you ok if we get this in during RC phase (like early next week) ?

I don't think we should attempt to add this to Spring Boot 3.3 if we can't get something in before our RC1. Perhaps I can take a look today and add the enum on our side then just make a minor amendment post RC to migrate the enum. That will at least give folks a chance to try it before we GA.

[onobc]

Perhaps I can take a look today and add the enum on our side then just make a minor amendment post RC to migrate the enum. That will at least give folks a chance to try it before we GA.

That would be excellent @philwebb . If you can't get to it, let me know and I would be happy to add it to the Boot side as well. I am already in progress on adding it to the Spring Pulsar side (which we would make the minor amendment post RC to switch the enum that is used).