Bugfix: use lock.extend replace pexpire

[laixintao]

monkey patch lua LUA_EXTEND_TO_SCRIPT

close #127
close #84
close #83

[laixintao]

Currently the process will die if it found out that it no longer own the lock:

[2019-05-29 23:38:09,366: DEBUG/MainProcess] beat: Releasing Lock
[2019-05-29 23:38:09,366: CRITICAL/MainProcess] beat raised exception <class 'redis.exceptions.LockNotOwnedError'>: LockNotOwnedError("Cannot release a lock that's no longer owned")
Traceback (most recent call last):
  File "/Users/laixintao/.virtualenvs/redbeat/lib/python3.7/site-packages/celery/beat.py", line 597, in start
    interval = self.scheduler.tick()
  File "/Users/laixintao/Program/redbeat/redbeat/schedulers.py", line 469, in tick
    self.lock.extend(int(self.lock_timeout))
  File "/Users/laixintao/.virtualenvs/redbeat/lib/python3.7/site-packages/redis/lock.py", line 246, in extend
    return self.do_extend(additional_time)
  File "/Users/laixintao/.virtualenvs/redbeat/lib/python3.7/site-packages/redis/lock.py", line 253, in do_extend
    raise LockNotOwnedError("Cannot extend a lock that's"
redis.exceptions.LockNotOwnedError: Cannot extend a lock that's no longer owned

I think it would be better to make this process get blocked and trying to reacquiring the lock?

[laixintao]

Hi @sibson some tests fails, but it doesn't seem to relevant to this PR. PTAL

[laixintao]

I update the lock extend logic and update readme. What do you think?

[sibson]

This generally looks good to me. I'm taken the approach of exiting on terminal error conditions rather than deal with the complexity of trying to recover.

[laixintao]

Conflict resolved. PTAL @sibson

[sibson]

LGTM, thanks. I'm going to see if we can resolve the failing test on master before merging this. If that doesn't happen soon, I'll merge this regardless.

[laixintao]

ping @sibson