advisory lock pollutes sys session by setting `innodb_lock_wait_timeout`

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
This is an internal session pool pollution bug, so it’s not directly observable.
In the `advisoryLock.GetLock` and `advisoryLock.IsUsedLock`, we set the session var `innodb_lock_wait_timeout` but didn't restore it in `advisoryLock.Close` and put it back to the pool directly. This may bring some potential risks.
https://github.com/pingcap/tidb/blob/321fffadda7e3ef10bfdca1d09e5bfb45c62a7e4/pkg/session/advisory_locks.go#L72-L77

https://github.com/pingcap/tidb/blob/321fffadda7e3ef10bfdca1d09e5bfb45c62a7e4/pkg/session/advisory_locks.go#L95-L98

https://github.com/pingcap/tidb/blob/321fffadda7e3ef10bfdca1d09e5bfb45c62a7e4/pkg/session/advisory_locks.go#L62-L66

### 2. What did you expect to see? (Required)
`GET_LOCK()` `IS_USED_LOCK()` should not change innodb_lock_wait_timeout for unrelated internal tasks. After the advisory-lock internal session is closed and returned to SysSessionPool, the original `innodb_lock_wait_timeout` should be restored.
### 3. What did you see instead (Required)
It's not restored.
### 4. What is your TiDB version? (Required)
master