feat: Migrate odata v2 and odata v4 to Apache HttpClient 5

[ricardosrib]

Context

This PR migrates the two higher-level OData modules v2 and v4 to Apache HttpClient 5, adding odata-core-apache-httpclient5 (OData v2) and odata-v4-core-apache-httpclient5 (OData v4) as HC5 siblings to the existing HC4 modules. It follows the earlier migration of the lower-level odata-client-apache-httpclient5 module and completes the HC5 migration path for OData consumers.

The migration preserves the existing public API — no breaking changes, at compile time or runtime — with one documented exception noted below.

Feature scope:

• Add odata-core-apache-httpclient5 module (OData v2, HC5)
• Add odata-v4-core-apache-httpclient5 module (OData v4, HC5)
• Migrate org.apache.http.* APIs to org.apache.hc.client5.* / org.apache.hc.core5.*
• HttpClientAccessor to ApacheHttpClient5Accessor, execute(...) to executeOpen(...)
• ConnectionPoolTimeoutException to ConnectionRequestTimeoutException
• Preserve the CSRF token control API withoutCsrfToken() for backward compatibility and depracate withCsrfToken() as the CSRF token retrieval is now handled centrally by the CsrfTokenInterceptor
• withoutCsrfToken() disables retrieval per request via an internal skip-marker header the interceptor honors and strips
• withCsrfToken() retained as a documented @Deprecated no-op
• Migrate and adapt all unit tests and their test resources to the new modules
• Register the two new modules in datamodel/pom.xml

Accepted behavioral difference between HC4 and HC5:

In HC4, calling withCsrfToken() on a read request builder forced a HEAD probe and attached a token to the GET. In HC5, CSRF handling is centralized in CsrfTokenInterceptor, which fetches tokens only for mutating methods (POST/PUT/PATCH/DELETE). So withCsrfToken() is now a @Deprecated no-op.

Not a breaking change: servers never validate CSRF tokens on safe methods like GET/HEAD, so a read returns the identical response either way.

Why only withoutCsrfToken() was kept functional

withoutCsrfToken() controls a mutating request (POST/PUT/PATCH/DELETE), where the CSRF HEAD probe is real and observable. Legacy code relies on it to suppress that fetch when the target doesn't use CSRF, so dropping it would cause unwanted HEAD probes and possible failures against servers that don't expect the fetch. So I kept it as an opt-out: it sets an internal skip header that CsrfTokenInterceptor detects and strips, so no token is fetched. CsrfTokenOptOutTest tests it for create/update/delete/batch/action.

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Documentation updated
• Release notes updated