_lock_id() shouldn't use drupal_static(), any cache clear would potentially make locks stall

Problem/Motivation

_lock_id() currently uses drupal_static() for its unique ID for the request. There is no reason for the additional overhead, because the request does not change during... the request. Furthermore, if something alters clears the cache, the token will be erased and will change at the next _lock_id() call. This means that the shutdown handler won't erase the original lock and it will be stuck.

Proposed resolution

Replace with a simple static variable declaration, and document why this is important in a comment.

Remaining tasks

D8 patch is RTBC in #1216886-4: _lock_id() shouldn't use drupal_static(), any cache clear would potentially make locks stall. Cherry-pick for D7 commit.

Consider overall issue of drupal_static() use in D8.

User interface changes

None.

API changes

None.

Original report by @pounard

Hello,

Actual _lock_id() implementation (default lock.inc implementation) uses drupal_static() for caching statically the unique page request identifier.

This drupal_static() usage is useless because the request doesn't change while running (WTF?!), and is dangerous because if someone messes up with drupal_static() cache, or clear it, the token will be erased and will change at the next _lock_id() call.

If this happens, the shutdown handler won't erase stalled locks set previousle to the drupal_static() cache clear.

Patch attached, should work for both 8.x and 7.x.