Improve the lock interface to better suit distributed locks

[Acconut]

The current lock inferface was primarily inspired by in-memory mutexes, where one can assume that an acquired mutex is valid until it is released again. These assumption do not hold up for distributed lock mechanisms and we should adjust the lock interface to accommodate those:

• Distributed locks often provide leases instead of mutexes. A lease has a specific lifetime, after which it expires and the lease is available to be grabbed by another entity. If the owner wants to continue holding exclusive access they have to extend the lease. This ensures that when the owning process dies, the lease is not locked forever, but is released after a given fixed duration. This means that our new inferface should
  • expose a method for extending the lease. This method is then regularly called by the tusd handler to ensure that the lease is extended while the request is being handled. This should be done by the request handler to ensure that the lease is not extended whenever the request handling is aborted or crashes.
  • return a context that is valid as long as a valid lease is held. If we are not able to extend the lease, the context should be cancelled as we cannot ensure anymore that we have exclusive access and any access must be immediately interrupted.
• The lock interface incorporates a feature for requesting releases for locks. However, this naming is not entirely correct because it requests the controlled abortion of the handling of another request. The ending of that will then cause the lock to be released. On a technical level, we could separate the locking interface from this messaging interface to make the system more composable. We could even think about making the messaging system more capable if there are use cases where tusd instances should communicate with each other.