Add NotionDatabaseItemReaderBuilder

[qlfyd123]

Changes

Created a builder class for NotionDatabaseItemReader and added corresponding test code for the builder.
This pr is related with #151

Questions/Suggestions

1. Inconsistency between documentation and implementation for sorts default value

According to the GitHub README, the default value for sorts is null. However, in the actual NotionDatabaseItemReader class, it's initialized with an empty Sort array:

private Sort[] sorts = new Sort[0];

Could you clarify whether this is intentional or if it needs to be aligned with the documentation?

2. Suggestion to use Assert.notNull instead of Objects.requireNonNull in constructor

Currently, the constructor uses Objects.requireNonNull for parameter validation:

public NotionDatabaseItemReader(String token, String databaseId, PropertyMapper<T> propertyMapper) {
    this.token = Objects.requireNonNull(token);
    this.databaseId = Objects.requireNonNull(databaseId);
    this.propertyMapper = Objects.requireNonNull(propertyMapper);
    this.pageSize = DEFAULT_PAGE_SIZE;
}

I suggest using Assert.notNull instead to provide clearer, more descriptive error messages, which would be more consistent with Spring conventions.

3. Missing @Nullable annotations on setter parameters causing IDE warnings

Given the current project configuration with @NullMarked at the package level:

/**
 * Spring Batch extension for Notion.
 */
@NullMarked
package org.springframework.batch.extensions.notion;

import org.jspecify.annotations.NullMarked;

All method parameters are treated as non-null by default. However, some setter methods in the reader class accept nullable parameters (e.g., setFilter) but lack @Nullable annotations. This causes IDE warnings when using the builder.

Would it be acceptable to add @Nullable annotations to the appropriate setter parameters to align with the null-safety contract?

[scordio]

@qlfyd123 thanks for raising the PR!

Could you clarify whether this is intentional or if it needs to be aligned with the documentation?

Yes, it was intentional, as I'd prefer to avoid null values. Still, as you correctly noticed, the default value for sorts in the README is incorrect, so I propose updating it to [].

I suggest using Assert.notNull instead to provide clearer, more descriptive error messages, which would be more consistent with Spring conventions.

Sure, it sounds good to me 👍

All method parameters are treated as non-null by default. However, some setter methods in the reader class accept nullable parameters (e.g., setFilter) but lack @Nullable annotations. This causes IDE warnings when using the builder.

Would it be acceptable to add @Nullable annotations to the appropriate setter parameters to align with the null-safety contract?

Keeping the setFilter parameter non-nullable was a deliberate choice I made, even though filter is internally nullable. My rationale is that I don't see a realistic use case that would require a setFilter(null) invocation. Because of this, you probably need to guard the invocation in the builder with a null check.

[scordio]

Thanks, just a few style comments.

[qlfyd123]

thx for review @scordio I have addressed all the feedback from the review. Specifically, I have updated the null checks to use Assert.notNull and corrected the issues in the test code. Please let me know if there's anything else to improve.

[scordio]

Thanks! Would you like to update the README, too?

Still, as you correctly noticed, the default value for sorts in the README is incorrect, so I propose updating it to [].

I can also take care of it.

[qlfyd123]

I updated README.md file and fix javadoc for ci workflow

[scordio]

Many thanks for your contribution, @qlfyd123!