Refactor @DataProvider methods in integration tests to use lazy initialization pattern

Description

Refactor integration test DataProvider methods to eliminate infrastructure initialization during test discovery phase. Current pattern calls APILocator and DataGen in @DataProvider methods which execute before @BeforeClass in test suites, causing random failures and cross-test contamination. Solution implements lazy supplier pattern with named test cases for clear test reporting. Affects 9 test files (8 bundler tests + 1 publisher API test).

See docs/testing/DATAPROVIDER_REFACTORING_GUIDE.md for complete refactoring pattern and examples.

Problem

When integration tests run in a suite, ALL @DataProvider methods from ALL test classes execute BEFORE any @BeforeClass methods run. This means:

• Infrastructure (database, Elasticsearch) is not initialized when DataProvider runs
• DataProvider methods from different test classes interfere with each other
• Random execution order causes non-deterministic failures
• Failures occur during test discovery, making debugging difficult

Solution

Implement Named TestCase Pattern with lazy initialization:

• @DataProvider returns TestCase wrappers with Suppliers
• Infrastructure calls moved to helper methods
• Suppliers evaluated lazily in test methods (after @BeforeClass)
• Clear test names for better reporting

Acceptance Criteria

Priority 1: Bundler Tests (8 files)

• ContainerBundlerTest.java - containers() method refactored
• TemplateBundlerTest.java - templates() method refactored
• ContentTypeBundlerTest.java - contentTypes() method refactored
• WorkflowBundlerTest.java - workflows() method refactored
• HostBundlerTest.java - hosts() method refactored
• FolderBundlerTest.java - folders() method refactored
• LinkBundlerTest.java - links() method refactored
• RuleBundlerTest.java - rules() method refactored

Priority 2: Publisher API Tests (1 file)

• PublisherAPIImplTest.java - publishers() method refactored (most complex)

Verification Requirements

For each refactored file:

• prepare() moved to @BeforeClass
• @DataProvider method has no infrastructure calls
• All helper methods return TestData objects
• TestCase class implements toString() with descriptive names
• Test method calls testCase.get() for lazy evaluation
• All tests pass when run individually
• All tests pass when run in suite
• Test names appear correctly in output

Additional Notes

Files affected:

• All in dotcms-integration/src/test/java/com/dotcms/enterprise/publishing/remote/bundler/
• Plus dotcms-integration/src/test/java/com/dotcms/publishing/PublisherAPIImplTest.java

Testing:

# Run specific test class
./mvnw verify -pl :dotcms-integration -Dcoreit.test.skip=false \
  -Dit.test=ContainerBundlerTest

Reference: Complete refactoring guide with step-by-step instructions and full example in docs/testing/DATAPROVIDER_REFACTORING_GUIDE.md

Start with docs/testing/DATAPROVIDER_REFACTORING_GUIDE.md and its example, then inspect the eight bundler test files under dotcms-integration/src/test/java/com/dotcms/enterprise/publishing/remote/bundler/ and PublisherAPIImplTest.java. Run ContainerBundlerTest with the provided Maven command first. Done means all nine providers use lazy TestCase evaluation, pass individually and in a suite, and produce descriptive test names.