[BugFix] Locker: rollback partial intensive-lock acquisition (backport #72423)

[mergify]

lockTableWithIntensiveDbLock and lockTablesWithIntensiveDbLock acquire a DB intention lock first and then one or more table locks. If any of the table-lock acquisitions threw (deadlock victim selection, interrupt, timeout, etc.), the helpers caught LockException and rethrew it as ErrorReportException without releasing the DB intention lock that was already held -- and, in the multi-table variant, without releasing any table locks acquired earlier in the loop. The result was a stranded IS / IX lock on the database that blocked subsequent DB-WRITE operations (DROP DATABASE / DROP TABLE / quota change / rename) indefinitely until the FE process restarted.

Callers could not work around this from the call site:

• Lock-acquisition outside try/finally: catch is never reached, the finally never runs, so the partial DB lock leaks.
• Lock-acquisition inside try/finally: the finally calls the matching unLock... helper, which first releases the DB intention lock (good) and then iterates the table-id list calling release on each -- but table locks past the failure point were never acquired, so their release throws and masks the original LockException with a less informative "lock not held" error. The DB lock is released in this case, but the diagnostics are wrong.

Fix the helpers themselves. On any LockException during acquisition, call a new private rollbackPartialIntensiveLock that releases each table lock that did get acquired (in acquisition order, like the existing tryLockTablesWithIntensiveDbLock pattern at lines 338-348), then releases the DB intention lock if it was acquired. Each release is wrapped in a defensive try/catch that logs and swallows any secondary error, so the original LockException surfaces to the caller instead of being masked by a release-side failure.

After this change, the lock-acquisition-outside-try/finally idiom at the call sites is correct: a partial-acquire failure leaves no held locks behind, so there is nothing for a finally block to release.

Why I'm doing:

What I'm doing:

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5
  • 3.4

---

This is an automatic backport of pull request #72423 done by [Mergify](https://mergify.com).