Replacing synchronized blocks with ReentrantLocks in core part of SDK

[Myllyenko]

Continuation of #338

[Myllyenko]

First log argument was absent

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 66.66667% with 6 lines in your changes missing coverage. Please review.

Project coverage is 47.21%. Comparing base (9a7adfa) to head (863193b).

Files with missing lines	Patch %	Lines
...src/main/java/tech/ydb/core/impl/YdbDiscovery.java	70.58%	4 Missing and 1 partial ⚠️
...a/tech/ydb/core/impl/call/ReadWriteStreamCall.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #341      +/-   ##
============================================
+ Coverage     47.19%   47.21%   +0.01%     
  Complexity     1750     1750              
============================================
  Files           311      311              
  Lines         12499    12499              
  Branches       1238     1238              
============================================
+ Hits           5899     5901       +2     
+ Misses         6140     6138       -2     
  Partials        460      460              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alex268]

I am not sure that we have to remove synchronized from call classes. They are just simple wrappers on GrpcCall and all their calls are not blocking. In this case, synchronized just adds thread safety to GrpcCall, especially with case data race on start() and cancel(). Replacing them by ReentrantLock makes them more complex and may reduce a performance

[Myllyenko]

I am not sure that we have to remove synchronized from call classes. They are just simple wrappers on GrpcCall and all their calls are not blocking. In this case, synchronized just adds thread safety to GrpcCall, especially with case data race on start() and cancel(). Replacing them by ReentrantLock makes them more complex and may reduce a performance

Reverted changes in StreamCalls.