TcpClient configuration takes more time than expected

[PrathibaJee]

The following operations takes more time than expected if the provided input is different from the already configured value,

• putTcpClientRemoteAddress
• putTcpClientRemotePort
• putTcpClientRemoteProtocol

This is because , during the configuration , connection to the elastic search instance will also be configured.
Currently , there is an "await" for this elastic search configuration , which makes the service to respond longer than expected in this case.
shall we make the elastic search configuration process as asynchronous , so that the result of the putTcpClient* will be independent.
(If you are fine with this proposal , please create issues in OL and ALT aswell, thanks)

Priority: low

[DanaSunal]

I would not make the call async.
If you put a port/protocol/address that actually does not lead to Elasticsearch, you (as user) will get 200, because the data will be written in the configuration, but the actual connection to ES will fail, but since it's not awaited, as user you'll never see the error and you'll be stuck with a non-working app seemingly without reason.

Other points for keeping the await:

1. all the mentioned methods have already a check which checks if the tcp client is ES client and ONLY in that case the call to ES is made (which limits this call to one TCP client per app).
2. in which use case is this time a bottleneck? How many times are we expecting that someone will be reconfiguring ES?