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.