[Fix][admin] Fix resource same-name overwrite not refreshing local rs cache

[fancy27]

Summary

• Invalidate tmp/rs local cache after resource same-name overwrite / delete so OSS/HDFS updates are picked up
• Rewrite rs:// local files atomically (delete + temp download + move) and disable URL caches to avoid stale JarFile/ClassLoader content in Session modes
• Fix parent directory size accounting on overwrite (use size delta instead of always adding)

Test plan

• Upload a jar to Resource Center (OSS), run a Flink Jar task on kubernetes-session referencing rs:/...
• Overwrite the same jar with a different version; confirm tmp/rs/... is removed/updated after upload
• Re-run the task without restarting Dinky; confirm the new jar behavior is used
• Delete the resource and confirm local tmp/rs cache for that path is cleared

[aiwenmo]

LGTM

[aiwenmo]

Thanks for the patch, and for tracking down the stale tmp/rs cache. Updating the file size and description on overwrite, and adjusting parent directory size by the delta instead of always adding the new size, fixes a real accounting bug. Clearing the local cache on delete is the right direction as well.

A few cases are still open, so this does not fully fix Session jobs reusing an old jar:

• setUseCaches(false) applies only to the rs:// download connection. RsURLConnection always calls readFile and does not use that cache. The stale content comes later, when PackagedProgram / URLClassLoader opens the same local file: URL. The JDK JarFileFactory caches by URL string, so deleting and rewriting the same tmp/rs/... path leaves the cached JarFile in place. A follow-up needs a new local path per version or content hash.
• Cache invalidation and cache writes use different path rules. clearRsLocalCache uses the DB fullName, while toFile uses URL.getPath(). rs:/dir/app.jar matches, but getFile() builds rs:// + fullName, which parses dir as the host and writes tmp/rs/app.jar while invalidation deletes tmp/rs/dir/app.jar.
• Every download uses the fixed sibling *.downloading. Two concurrent toFile calls for the same resource can interleave writes, and a later move can put the old bytes back after invalidation.
• clearRsLocalCache runs inside the upload transaction, after the remote putFile. If the local delete fails, the transaction rolls back the DB size while OSS/HDFS already has the new object. Other Dinky nodes also keep their own tmp/rs copy.
• The create-new-file branch still does x.getSize() + size, so a null parent size NPEs. There is no automated coverage for overwrite, delete, or concurrent download.

We will treat this as an incremental fix and merge it first. The Session classloader cache, a single path helper, unique temp files, and not rolling back a successful remote write should go into a follow-up PR.