refactor: remove manual deletion of channel resources or objects

[girishc13]

Goals:

• resolves refactor: extract GrpcConnectionPool implementation into a package #5622
• In the reset_connection method, the channel was being manually deleted using the del keyword which can cause segmentation fault if another co-routine was having a reference the deleted channel. The alternatives to avoid deleting the channel reference are:
  1. use a Lock to detect usage or
  2. allow the GC to collect the unused channel when all references have been removed.
• The ii choice is more straight forward since the co-routines that maybe holding a channel are usually short lived due to the timeout on the request. Also destroying the channel has very little benefit because the underlying TCP connection will be reused or recreated by the new connection.
• The removed channel doesn't need to be returned because there is no further usage.

[codecov]

Codecov Report

Merging #5633 (79571b6) into master (02edb74) will increase coverage by 17.90%.
The diff coverage is 85.71%.

@@             Coverage Diff             @@
##           master    #5633       +/-   ##
===========================================
+ Coverage   70.38%   88.28%   +17.90%     
===========================================
  Files         129      131        +2     
  Lines       10179    10200       +21     
===========================================
+ Hits         7164     9005     +1841     
+ Misses       3015     1195     -1820     

Flag	Coverage Δ
jina	88.28% <85.71%> (+17.90%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
jina/clients/__init__.py	96.87% <ø> (+18.75%)	⬆️
jina/orchestrate/flow/base.py	89.62% <ø> (+11.26%)	⬆️
jina/serve/networking/replica_list.py	89.24% <80.00%> (+22.00%)	⬆️
jina/serve/networking/connection_pool_map.py	97.36% <100.00%> (+11.47%)	⬆️
jina/resources/health_check/pod.py	50.00% <0.00%> (ø)
jina/resources/health_check/gateway.py	41.17% <0.00%> (ø)
jina/orchestrate/pods/__init__.py	88.05% <0.00%> (+0.62%)	⬆️
jina/proto/pb2/jina_pb2_grpc.py	76.00% <0.00%> (+1.00%)	⬆️
jina/jaml/parsers/__init__.py	97.72% <0.00%> (+2.27%)	⬆️
jina/serve/gateway.py	95.31% <0.00%> (+3.12%)	⬆️
... and 73 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[girishc13]

I opened a bug ticket related to custom logging configuration. The logging check using a FileHandler was one potential way to check the reconnect attempts. Due to multiprocessing using instrumentation might be the only other way.