feat: Implement the clear and task APIs

[edeandrea]

Also enabled parallel builds & build caching for performance.

As part of this I did some refactoring as well (all backwards-compatible).

• I refactored DoclingServeApi into smaller interfaces that match the operations within docling serve (chunk, clear, convert, health, task)
• The DoclingServeApi simply extends all of them, but the operation definitions have been moved down into separate interfaces.
• This will also allow consumers who only care about docling-serve-api to implement the parts of the api that they want to.

I did a similar refactoring to match in DoclingServeClient.

• DoclingServeClient still implements all of the methods directly, but it delegates to various Operations classes that implement the actual apis.

All-in-all it doesn't affect functionality, but I feel it improves readability & maintainability.

I also refactored AbstractDoclingServeClientTests to introduce @Nested classes, again 1 each for the various APIs.

Fixes #188

[github-actions]

	Tests	Passed ✅	Skipped	Failed
Gradle Test Results (all modules & JDKs)	570 ran	570 passed	0 skipped	0 failed

Test	Result
No test annotations available

• View Gradle Test Results (all modules & JDKs)

[edeandrea]

@ThomasVitale / @oscerd one thing I went back and forth on was the best way to model things that are path/query parameters.

Most of the other operations are POSTs where the uri is "static" and the request object we build is marshalled to json and sent in the request body.

With the task & clear apis, some of the uris have path & query parameters, and mostly are GETs. In this PR I modeled it as a request object, like this for example

@lombok.Builder(toBuilder = true)
@lombok.Getter
@lombok.ToString
public class TaskStatusPollRequest {
  public static final Duration DEFAULT_STATUS_POLL_WAIT_TIME = Duration.ZERO;

  @lombok.NonNull
  private String taskId;

  @lombok.Builder.Default
  @lombok.NonNull
  private Duration waitTime = DEFAULT_STATUS_POLL_WAIT_TIME;
}

And the corresponding operation is defined as TaskStatusPollResponse pollTaskStatus(TaskStatusPollRequest request);

In this case there isn't any serialization because the object itself is never serialized. The taskId is a path parameter and the waitTime is a query parameter in the http request.

Would it be better to not include things that are path/query params in these request objects, and instead make them parameters of the operation itself?

So

TaskStatusPollResponse pollTaskStatus(TaskStatusPollRequest request);

would become

TaskStatusPollResponse pollTaskStatus(String taskId, Duration waitTime);

It makes the method more fragile, but that might be a good thing since these are required things in the API. The more I think about it the more I think we should only model things that are part of a request/response body. These other things should go directly into the operation's method signature.

Thoughts?

[edeandrea]

After thinking about it more, I decided to go ahead and make the change. Things that are required that are outside the request body (i.e. path/query params) I added directly to the method signature.

[oscerd]

I started to work on the async support part, I'll have to aligned with this once it is merged.

[github-actions]

HTML test reports are available as workflow artifacts (zipped HTML).

• Download: Artifacts for this run

[github-actions]

:java_duke: JaCoCo coverage report

Overall Project	40.84%	🔴

There is no coverage information present for the Files changed

[github-actions]

HTML test reports are available as workflow artifacts (zipped HTML).

• Download: Artifacts for this run

[docling-java-ops]

🎉 This issue has been resolved in v0.4.0 (Release Notes)