UnitTest: log to stdout

By printing the log messages to stdout, they will be captured by nose,
thus not disturbing the user. Should a test fail, the messages will
still be displayed.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
UnitTest: Enable custom context

Should the user want to use a custom context implementation, he can use
the with_custom_context decorator to do that. It enables users to
inherit from TestContext, extend its functionality, and use the extended
version in a test. This could be useful if someone wanted to use a
custom implementation for `open`.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: [UnitTest] Test to reproduce gc error

This test will reproduce the issue that was seen in the referenced
ticket. 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 prints a message.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Fix lockfile attribute in Lock

As Lock's destructor was assuming that lockfile attribute exists, it
printed out an AttributeError on stdout while the GC was cleaning it up.
This fix initialises the lockfile field in the constructor.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Add seam for file call

Extract the file call to a separate method, so that the extracted method
could be used in tests as a seam, emulating situations like: what would
happen if the file call failed.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: [UnitTest] Test file not found int lock

These are test cases covering the lock module, and also testing what
happens if an open operation raises an IOError. This can happen as a
race condition, if two locks - A and B are created in the same namespace
and by the time A gets to open the lockfile, B already cleaned up the
namespace.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
CA-140596: Fix file creation error

If creating the lockfile failed with IOError having ENOENT error code,
that means that another lock within the same namespace already cleaned
up the namespace. With this change, should IOError happen with ENOENT,
the lock will re-create the namespace, and the file 10 times, and only
bubble up the exception if it failed all those retries.

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