fix disabling redbeat_lock feature

[bertosantamaria]

In situations where RedBeat lock is not needed we are unable to disable this feature. This PR allows user to disable lock by omitting or assigning None in the config.
#101

[sibson]

Without looking deeper, I'm not sure how the Config is handled. Does this change the default behaviour? I'm concerned existing users relying on the lock will suddenly find it stopped working for them if they didn't explicitly enable it.

[bertosantamaria]

@sibson, I see your point. What if there was another config key that allowed toggling the use of the redbeat_lock_key. Something like:

1. If you set "redbeat_use_lock" to False then you disable RedBeat's lock feature regardless of what you set for "redbeat_lock_key".
2. If you set "redbeat_use_lock" to True or omit it completely from your config then RedBeat will use your value of "redbeat_lock_key" or default to using "redbeat_key_prefix"+":lock" for the lock (current behavior.)

#config keys and values
redbeat_lock_key: user supplied | redbeat_key_prefix + ':lock'
redbeat_use_lock: True|False

Pros:

• keeps the code backwards compatible
• allows users to actually disable the lock
• uses lock by default

Cons:

• adds another key to the config to control the lock which could be confusing (will make docs clear)

[sibson]

That seems like a reasonable solution. I wish I'd done it right the first time :)

Would it be more clear to call it readbeat_ensure_only_one or redbeat_singleton? I've no attachment to any particular name.

[joekohlsdorf]

This PR is in conflict with the current README and doesn't address that change:

RedBeat uses a distributed lock to prevent multiple instances running. To disable this feature, set:
redbeat_lock_key = None

I also strongly advise against disabling locking by default which this change does.
A second config key is not necessary to fix this. The real bug is that overwriting default configuration values does not work as expected.