Refactor common parts from the Rounding class into a separate 'round' package

[ketanv3]

Description

The Rounding class (permalink) is a 1.5K SLOC monolith which is closely tied to rounding down timestamp values. This PR aims to simplify this class by:

• Decoupling generic rounding classes (i.e., the ones not related to rounding of timestamp values) into a separate common package.
• Creating the common package under the :libs:opensearch-common module as it's no longer tied to the :server module.

Related Issues

This is a prerequisite for #10392 which requires parts of the Rounding class to be overridden with SIMD features on supported JDKs. Since Multi-Release JAR replaces the entire class file (no way to replace just the inner classes), it creates too much code duplication. Splitting the Rounding class into smaller pieces and overriding them is much better.

relates #5910 - refactor to support modularity
relates #8110 - JPMS meta issue

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)
• Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

Compatibility status:

Checks if related components are compatible with change 370cdad

Incompatible components

Incompatible components: [https://github.com/opensearch-project/performance-analyzer.git]

Skipped components

Compatible components

Compatible components: [https://github.com/opensearch-project/geospatial.git, https://github.com/opensearch-project/security-analytics.git, https://github.com/opensearch-project/observability.git, https://github.com/opensearch-project/notifications.git, https://github.com/opensearch-project/job-scheduler.git, https://github.com/opensearch-project/neural-search.git, https://github.com/opensearch-project/custom-codecs.git, https://github.com/opensearch-project/asynchronous-search.git, https://github.com/opensearch-project/opensearch-oci-object-storage.git, https://github.com/opensearch-project/reporting.git, https://github.com/opensearch-project/ml-commons.git, https://github.com/opensearch-project/index-management.git, https://github.com/opensearch-project/common-utils.git, https://github.com/opensearch-project/cross-cluster-replication.git, https://github.com/opensearch-project/anomaly-detection.git, https://github.com/opensearch-project/sql.git, https://github.com/opensearch-project/alerting.git, https://github.com/opensearch-project/security.git, https://github.com/opensearch-project/k-nn.git, https://github.com/opensearch-project/performance-analyzer-rca.git]

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/29355/
• CommitID: 7cf6fc7
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[ketanv3]

All unrelated test failures:

• [BUG] AzureBlobContainerRetriesTests.testReadRangeBlobWithRetries flaky test failure #6090
• [BUG] org.opensearch.cluster.MinimumClusterManagerNodesIT.testThreeNodesNoClusterManagerBlock flaky #10006
• [BUG] Flaky test org.opensearch.remotestore.RemoteStoreStatsIT.testNonZeroPrimaryStatsOnNewlyCreatedIndexWithZeroDocs #10983

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/29424/
• CommitID: 3d7a3f4

[kkmr]

My memory of this is that if number of elements is < 64, we use LinearSearch, if number of elements < 128, we use BinarySearch. Is that not accurate? I think I added a comment to that effect in the previous PR.

[ketanv3]

My memory of this is that if number of elements is < 64, we use LinearSearch, if number of elements < 128, we use BinarySearch. Is that not accurate? I think I added a comment to that effect in the previous PR.

@kkmr Yes, that still holds true for the date_histogram aggregation.

This PR refactors out the common parts that aren't related to timestamps or aggregations. It simply provides the fastest implementation of Roundable for any input size. The responsibility of using array-based prepared rounding if the size is <= 128 is kept with the caller (here).

[ketanv3]

@nknize @reta Are we good to merge this PR?

[ketanv3]

Ping @nknize

[github-actions]

✅ Gradle check result for 370cdad: SUCCESS

[ketanv3]

@andrross Are we all set to merge this PR? I have another draft PR (#11194) that hinges upon these changes.

Nick's comment has been addressed

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-11023-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 08db961e1914d93ce9d81e6da84e6e232b8d37e2
# Push it to GitHub
git push --set-upstream origin backport/backport-11023-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-11023-to-2.x.