Add TeamsLock

[idanarye]

• Create a lock with a list of teams.
• When entering the lock you must declare your team.
• If the lock is acquired by your team you may enter.
• If the lock is acquired by a different team you will block.

[idanarye]

This is something I wanted to insert a while ago, but @koreno said my use-case is not good enough. Well - now it is!

When we start/stop Stress0 we need to pause the Mayhem - S0 can handle failures while it runs but not during the start/stop sequences. We used to have only one thing starting/stopping S0(the test), so RWLock was good enough - the mayhem actions were the readers and the test was the writer and multiple actions could run together but not when the test is trying to do things.

Now that we have filesystem actions, this is not enough:

• When we remove a filesystem group, we need to remove it's filesystems first
• When we remove a filesystem, we need to stop stress0 on it
• Stopping S0 takes some time, so we want to parallelize the process
• But... if every stop-S0-on-filesystem thread will try to pause the mayhem in parallel - they'll just block each other(multiple writers)

As a poor man's TeamsLock I've strapped a singleton_contextmanager_method on the mayhem pause - but this does not work very well(#44). So I want to add TeamsLock as a solution to this problem.

P.S.: This can be solved by locking before starting the concurrent subtasks, but we have four levels(entire system(during cleanup), filesystem group, filesystem and snapshot), and each must be aware of whether or not it is the top level. This can become quite a mess...

[koreno]

So which teams would we have in our Mayhem/Stress0 scenario?