virttest.utils_env_unittest: Add clean reproducer for the 'RuntimeError' issue

Sometimes, while virt-test is saving Env to a file, the
tcpdump thread writes to the Env dictionary "address_cache",
generating a:

RuntimeError: dictionary changed size during iteration

exception. Of course, any thread that modifies env data
while saving is taking place is going to create this
problem. So I implemented a similar situation in the
Env unittest code, so we have a reproducer, that can
be later fixed to use new Env locking mechanisms.

So, in case it is not clear, this unittest is supposed
to fail right now, and after said locking mechanism
is implemented, the test will start passing.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
virttest.utils_env: Solve the env["address_cache"] RuntimeError issue

There is a background tcpdump thread that records DHCP leases
in the env["address_cache"] dictionary. Sometimes, this thread
might write to this dictionary while the environment object is
being saved, triggering a RuntimeError in virt-test.

So the solution involves:

1) Creating a save lock, (a threading reentrant lock object),
that is acquired by the env.save() method when it wants to
save env.data to a pickle file, and for methods that alter
env.data.

2) Move the tcpdump thread to a env object attribute, rather
than one of the keys of env.data, given that the lock object
can't be pickled.

With the implementation of env.save_lock, we can also fix
the problem identified by the locking unittest. The base of
the solution was Pavel's idea, including a good deal of the
implementation, so kudos to him.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
virttest.utils_env: Add @utils_env.lock_safe decorator

Add a utility method to wrap functions that modify the
contents of env.data. In order to avoid the boring
repetition of code that gets an environment save lock,
perform data change and then release the lock, put that
into the decorator and use it.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>