Harmonize and enhance Javadoc comments across Elasticsearch codebase

[landawn]

• Reviewed and updated Javadoc for 145 Java files across all major modules
• Enhanced 800+ public methods with comprehensive documentation
• Added 200+ practical usage examples using standard template format
• Harmonized documentation for similar methods across the codebase
• Ensured all public methods have complete @param, @return, @throws tags
• Updated class-level documentation with clear purpose and usage guidance

Coverage:

• Server module: action, cluster, index, search, common, and other packages
• Libs: CLI, core, dissect, geo, grok modules
• Modules: health-shards-availability, ingest-attachment, ingest-otel, kibana, runtime-fields-common, systemd
• Plugins: analysis (ICU, Kuromoji, Nori, Phonetic, SmartCN, Stempel, Ukrainian), discovery-ec2, mapper-size, store-smb
• X-Pack: core (license), esql, ml, async, frozen-indices, graph, mappers, vector-tile, shutdown, and other plugins

Key improvements:

• Consistent documentation structure and terminology
• Accurate descriptions reflecting actual implementation
• Enhanced clarity with proper parameter and return value explanations
• Added usage examples demonstrating real-world patterns
• Cross-references to related classes using @link and @see tags

All changes maintain valid Javadoc syntax and follow Elasticsearch documentation standards.

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• If submitting code, have you built your formula locally prior to submission with gradle check?
• If submitting code, is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed.
• If submitting code, have you checked that your submission is for an OS and architecture that we support?
• If you are submitting this code for a class then read our policy for that.

[cla-checker-service]

❌ Author of the following commits did not sign a Contributor Agreement:
88ec4ad

Please, read and sign the above mentioned agreement if you want to contribute to this project

[DaveCTurner]

Quoting these guidelines:

We normally immediately reject isolated PRs that only perform simple refactorings or otherwise "tidy up" certain aspects of the code. We think the benefits of this kind of change are very small, and in our experience it is not worth investing the substantial effort needed to review them. This especially includes changes suggested by tools.

[landawn]

@DaveCTurner and all, Sorry for this PR. I ran Claude code to general javadoc for test and created this PR by mistake. That's not my intention. However, If any of you think that's a good idea. I may create another official PR when I find time.

[DaveCTurner]

However, If any of you think that's a good idea. I may create another official PR when I find time.

Sorry for being direct here but no that is not something we'd want. If we ever need a nicely-worded but questionably-accurate summary of some code we can ask a LLM ourselves, but I cannot imagine us ever having the capacity to go through a +8,609 −419 PR to check all the changes for accuracy, nor would we merge such a PR without so checking it.

[landawn]

@DaveCTurner Understood — it's just a test. The PR was meant to be created for the fork. That said, I’d suggest you or your team consider trying an LLM to generate the Javadoc.