CA-140596: [UnitTest] Test to reproduce gc error

This test will reproduce the issue that was seen in the referenced
issue. Whenever a new Lock instance is created, and the file() call
fails, the instance's lockfile attribute remained uninitialised. As the
instance has a custom destructor, that will be called by the garbage
collector. That function assumes that the instance has a lockfile
attribute, and thus raises a message.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Make Lock garbage collectable

Initialise a None lockfile attribute in Lock's constructor, as the field
is assumed to be existing in the destructor (_close)

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Fix lock concurrency issue

If the namespace directory was cleaned up before Lock tried to open the
lockfile, it would result the IOError to bubble up. To avoid this
situation, the lockfile creation will be re-tried until it succeeds.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Implement retry module

This module holds the retry logic, when a failure is ignored and should
be retried.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Wire-in retry module

Namespaces are used both at the refcounter and the lock module. This
change will use the same retry mechanism for both putposes.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>