Make Lock a first-class citizen

[paras-malhotra]

The Laravel Framework currently uses locks for several things:

1. The WithoutOverlapping middleware to avoid overlapping jobs
2. Unique jobs (PR pending)
3. Session blocking

Additionally, some Laravel users use Cache::lock in their apps.

The current lock implementation is tied with the cache driver. There are numerous drawbacks to this approach:

1. There is no distinction between the lock driver and cache driver. So, for example, there's no way to use the Redis cache and the database lock in tandem. With the current implementation, both have to originate from the same cache driver (unless you new up a DatabaseLock, however with this approach you cannot reap the benefits of dependency injection).
2. Cache is meant to store data that is temporarily stored in memory for frequent access. However, the same data is meant to be "immune" to cache clears. That is not the case with locks. So imagine running php artisan cache:clear only to break your session blocking or unique jobs.

How do we make lock a first citizen?

1. Implement a LockServiceProvider that maps the Lock interface to the concrete lock implementation via a LockManager and config/lock.php. This way we can separate the database / connection for lock and a php artisan cache:clear will not clear the lock and also, there's a clear distinction between implementation of the lock vs the cache.
2. Implement a Lock facade.

I think this would be a clean way to solve the problems described above. Thoughts?

Ping: @royduin