[entropy.db*] EntropyRepository, do not close() on object destruction

Closing the underlying sqlite3 db on object destruction (__del__())
causes funny race conditions when concurrently accessing the object
itself.

When the Garbage Collector tries to free memory, which can happen
when no more references pointing to self are used, by calling __del__()
(which called close()) it is possible to run into troubles if another
thread is inside a method of the same object holding a valid sqlite cursor.

Moreover, no external arbitration is possible if the garbage collection
gets in the middle and calls close() through the destructor on behalf
of a poor random innocent thread.

Solution is simple, destructor is evil and resource leaks have to be
handled where they actually are. Bye bye __del__().

lib/entropy/client/interfaces/db.py

@@ -109,11 +109,6 @@ class CachedRepository(EntropyRepository):
                     "cannot close this repository directly. Software bug!")
         return EntropyRepository.close(self)
 
-    def __del__(self):
-        """
-        Cannot honor the constraint in this case, sorry!
-        """
-        return EntropyRepository.close(self)
 
 class InstalledPackagesRepository(CachedRepository):
     """

lib/entropy/db/__init__.py

@@ -754,9 +754,6 @@ class EntropyRepository(EntropyRepositoryBase):
             self._discardLiveCache()
         return self._live_cacher.get(self._getLiveCacheKey() + key)
 
-    def __del__(self):
-        self.close()
-
     @staticmethod
     def update(entropy_client, repository_id, force, gpg):
         """