Removed _recvlock acquire/release from sync request; while it makes i…

…t significantly more likely that the sync request response goes to the correct thread, calling acquire/release here seems to cause a dead lock in some cases like that provided in #492; ultimately RPyC requires the design around threading and locks to be fleshed out... quite a number of users get confused w/ RPyC threading... RPyC offers a number of functions/classes that are temperamental w/ threading

rpyc/core/protocol.py

@@ -480,9 +480,7 @@ def sync_request(self, handler, *args):  # serving
         # AsyncResult will be constructed and it is possible GIL switches
         # threads before AsyncResult.wait is invoked. So, using an rlock
         # we acquire once here and once inside of wait which invokes serve
-        self._recvlock.acquire()
         value = self.async_request(handler, *args, timeout=timeout).value
-        self._recvlock.release()
         return value
 
     def _async_request(self, handler, args=(), callback=(lambda a, b: None)):  # serving