Update to host ip discovery algorithm for ports checker

Description

This change updates the algorithm for discovery of the external IP address, used for checking free ports for Postgres db clones. After recent upgrade DBLab from 2.4.1 to 3.5.0 I've discovered the engine container being stuck on startup due to failure during execution of provision.RevisePortPool() function.

As per my findings, root cause of this was an incorrect algorithm of determining host ip address inside function provision.hostIP(): it picks up newly created bridge network gateway IP address, normally for the network next to default this is set to 172.18.0.1, and if there is none, runs "/sbin/ip route | awk '/default/ { print $3 }'" inside container.

Because DBlab container has already been joined new docker network, approach with calling /sbin/ip utility erroneously returns the same gateway IP 172.18.0.1 for bridged network created by DB lab.

This is an incorrect approach, Since IP address is merely a gateway with no adapter present, you cannot checks ports availability with ports dialing. Only default bridge network has real IP address with adapter, used for host network communication, all other bridge networks you might create are not. In my case all ports validations ended in failure with error during port dialing.

With all the above, I've updated the algorithm, so now for determining host IP address, "CloneAccessAddresses" property from dblab config is used instead, with reasonable fallbacks in case user enters there "127.0.0.1" and "0.0.0.0".

I suppose it would be the better approach, because this config value expected to be set to the addresses, reachable to the external parties, and having real network adapters.

Checklist

• MR description has been reviewed
• MR changes are functionally tested
• MR does NOT have API/CLI changes OR there are API/CLI changes and they have been reviewed & DOCS ARE ADJUSTED (reference doc, etc)
• MR does NOT have UI changes OR there are UI changes and they have been reviewed & UX IS REVIEWED