Preserve MongoDB listener container startup behavior

[fregulha]

What's changed?

• Added PreserveDefaultMessageListenerContainerStartup, which preserves manual startup behavior for Spring-managed DefaultMessageListenerContainer beans during migration to Spring Data MongoDB 5.0.
• The recipe adds setAutoStartup(false) when the transformation can be performed safely.
• Existing explicit setAutoStartup(...) configurations remain unchanged.
• Unsupported configurations are marked for manual review.
• Integrated the recipe into UpgradeSpringDataMongoDb_5_0.
• Added unit tests and a composite-recipe integration test.
• Updated the recipe catalog and parser classpath resources.

What's your motivation?

Spring Data MongoDB 5.0 automatically starts DefaultMessageListenerContainer beans. Applications that previously started these containers manually could experience an unintended behavior change after upgrading.

This recipe preserves the previous behavior by explicitly disabling automatic startup where appropriate.

• Fixes [Spring Data MongoDB 5.0] Migrate removed MongoDB JMX support without breaking compilation #1085

Anything in particular you'd like reviewers to focus on?

The detection of supported @Bean factory methods, preservation of existing explicit startup configuration, and manual-review handling for configurations that cannot be transformed safely.

Anyone you would like to review specifically?

No specific reviewer.

Have you considered any alternatives or workarounds?

Users could identify and update each listener container manually, but including this transformation in the MongoDB 5.0 migration recipe makes the upgrade safer and repeatable.

Any additional context

The dedicated recipe and composite MongoDB 5.0 migration test suites pass successfully. Recipe marketplace CSV and license validations also pass.

The complete test suite was attempted on Windows. Six tests outside the affected packages failed: three import expectation tests in GetErrorAttributesTest and three Unix path-separator assertions in RenameLogbackToLogbackSpringTest.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[Kyran121]

Hi @fregulha - I believe this is tackling #1084, not #1085. I also opened #1119 around the same time as you to tackle the DefaultMessageListenerContainer autoStartup migration.

My implementation covers a broader set of @bean return patterns, including direct construction, locally-declared containers, multiple and nested return paths, locally assigned fields, same-named variables in separate scopes, reassignment, and simple one-hop same-class helper methods. It evaluates each return path independently and tracks variables by JavaType.Variable identity, so supported paths can still be migrated even where another return path in the same bean needs manual review.

It also preserves explicit setAutoStartup(...) configuration on a per-path basis and, for supported helper methods, configures the value returned from the bean rather than modifying the helper itself. This avoids changing the behaviour of other bean or non-bean callers that may share that helper.

For cases where the container provenance cannot be established safely — such as deeper helper chains, cross-class calls, or fields without a locally-visible assignment — it leaves the return unchanged and adds a targeted diagnostic for manual review.

It looks like our PRs overlap substantially, so it would probably make sense to align on which implementation to take forward.