Support IsEmpty and IsNotEmpty keywords in derived queries

[backend-choijunhyeong]

Add support for IsEmpty and IsNotEmpty repository query keywords in derived queries.

Why

The documentation lists IsEmpty as a supported keyword, but it throws
"Unsupported keyword" exception when used.

Changes

• Add IS_EMPTY and IS_NOT_EMPTY case handling in MongoQueryCreator.from()
• Add createIsEmptyCriteria() and createIsNotEmptyCriteria() methods
• String properties: { field: { $eq: "" } } / { field: { $ne: "" } }
• Collection properties: { field: { $size: 0 } } / { field: { $not: { $size: 0 } } }

Resolves #4606

[backend-choijunhyeong]

I'd like to clarify the expected behavior regarding null values.

Current implementation

• IsEmpty: matches only "" (empty string) or size: 0 (empty collection)
• IsNotEmpty: matches anything that is not "" or size: 0

This means null values are NOT considered "empty".

Question
Should IsEmpty also match null values?
For example: findByFirstNameIsEmpty -> should it return documents where firstName is null?

Options

1. Current: null is NOT considered empty (strict interpretation)
2. Alternative: null OR "" is considered empty (lenient interpretation)

I can adjust the implementation based on the team's preference.

[christophstrobl]

Thank you @backend-choijunhyeong for putting time into this.

I think the handling of String and Collection like properties is fine. There are dedicated keywords for null checks, so using $eq/$ne and $size works well.
It might be worth mentioning that blank String values (containing only whitespaces) should also not be considered empty (which is already the case).

Map like structures are not covered yet and should IMO be compared against an empty Document. Same goes for complex/domain types like an Address.

Having some integration tests in AbstractPersonRepositoryIntegrationTests would be good. This allows to verify the queries behave as expected and in the same way througout different scenarios (like for AOT generated code).

Let me know if that helps and if you'd like to continue working on the issue or if we should take it from here.

[backend-choijunhyeong]

Thank you for the feedback @christophstrobl !

I'd like to continue working on this.

I will

• Add support for Map and complex/domain types by comparing against an empty Document
• Add integration tests in AbstractPersonRepositoryIntegrationTests

I'll update the PR once the changes are ready.

[backend-choijunhyeong]

@christophstrobl

I have updated the implementation to address your feedback

• Added support for Map and complex types (compares with an empty document {}).
• Added integration tests for String, Collection, Map, and domain types.

Question
Regarding your mention that "Numeric values should error," should I add explicit validation to throw an exception for numeric types, or is the current behavior acceptable?

Thank you for the review.