Fixed UDF jar metadata handling in UDFInfo when multiple UDFs share the same jar

[Caideyipi]

Description

This PR fixes UDF jar metadata handling in UDFInfo when multiple UDFs share the same jar.

Background

UDFInfo previously tracked uploaded jars only with jarName -> md5. When a UDF was dropped, the jar metadata was
removed immediately. This breaks the case where multiple UDFs reference the same jar:

• dropping one UDF can make ConfigNode think the shared jar no longer exists
• later validation may no longer detect conflicting MD5 values for the same jar name
• after snapshot load, jar metadata is restored but shared-jar reference state is not rebuilt, so the same issue can
  reappear after restart

Changes

This PR introduces reference counting for shared UDF jars in UDFInfo.

• add existedJarToReferenceCount to track how many UDFs are using each jar
• update UDF creation flow to increase jar reference count instead of only recording MD5
• update UDF drop flow to remove jar metadata only when the last reference is removed
• rebuild jar metadata and reference counts from the UDF table after loading a snapshot

This keeps shared jar metadata consistent across normal create/drop operations and snapshot recovery.

Tests

Updated UDFInfoTest to cover the shared-jar cases:

• dropping one UDF does not remove jar metadata if another UDF still references the same jar
• validation still rejects the same jar name with a different MD5 after one reference is dropped
• snapshot load rebuilds shared-jar metadata correctly, and subsequent drop behavior remains correct

---

This PR has:

• been self-reviewed.
  • concurrent read
  • concurrent write
  • concurrent read and write
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods.
• added or updated version, license, or notice information
• added comments explaining the "why" and the intent of the code wherever would not be obvious
  for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold
  for code coverage.
• added integration tests.
• been tested in a test IoTDB cluster.

---

Key changed/added classes (or packages if there are too many classes) in this PR

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.56%. Comparing base (7563ac8) to head (2c62c39).

Files with missing lines	Patch %	Lines
...g/apache/iotdb/confignode/persistence/UDFInfo.java	87.50%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #17732      +/-   ##
============================================
+ Coverage     40.55%   40.56%   +0.01%     
- Complexity     2574     2575       +1     
============================================
  Files          5179     5179              
  Lines        349896   349918      +22     
  Branches      44727    44731       +4     
============================================
+ Hits         141890   141954      +64     
+ Misses       208006   207964      -42     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[luoluoyuyu]

Review summary

Reference counting for shared JARs fixes incorrect removal of existedJarToMD5 when only one of several UDFs is dropped. rebuildJarMetadataFromUDFTable() keeps jar metadata consistent after snapshot load. New unit tests cover the shared-jar and snapshot paths.

Two small suggestions below; otherwise this looks good to merge.

[luoluoyuyu]

putIfAbsent keeps the first MD5 for a jar name but always increments the reference count. That is fine when validate() runs before addUDFInTable, but if addJarReference is ever called without that check, ref count and MD5 could diverge.

Consider rejecting a conflicting MD5 inside addJarReference (same check as in validate() at lines 107-115) so this helper is safe on its own.

[luoluoyuyu]

After deserializeExistedJarToMD5, rebuildJarMetadataFromUDFTable() clears both maps and rebuilds from udfTable. That makes udfTable the source of truth on load.

A short comment here explaining that deserialized existedJarToMD5 is intentionally discarded would help future readers.