Make remote docker daemon setup with HTTP networks easier

Describe why it is important and where it will be useful

There are some specific conditions applied to the HTTP daemons in the setup of deploy daemon with docker socket proxy. In general HTTPS daemons ("Enable HTTPS" option checked) have been allowed and considered as remote deployments on remote servers with the assumption of the network in between being insecure.
This is the case for many but some setups can have the second ex-app server in the internal network itself or even in actually remote server, can have a VPN setup to facilitate secure communication.
Setting up HTTPS on the ex-app server in these cases may add a little overhead, may be secured with a self-signed certificate which would have to be trusted by the NC server, or when setting up a HTTP daemon, the issue may not present itself until the test deploy/app install phase.
The override for using the HTTP remote daemon is OVERRIDE_APP_HOST setting in the additional options menu, which is a little hidden and can also be hard to understand.

Allowing remote HTTP setups may not be that much insecure since admins can be trusted to understand their network setup (for the most part).
This only applies to Docker Socket Proxy.

Describe your proposed solution

• Introduce new additional option to indicate remote setup, that is changing the logic of how ExApp host is resolved when HTTP is used.
  For this new option we need a migration to set it for existing daemons that already configured as remote (https enabled).
• For the UI part of Register daemon and Test Deploy add more explicit hints on available configuration options that might help in case of heartbeat/init errors.
• Add a warning in the registration UI if the daemon is marked as a remote daemon without HTTPS.
• For Test deploy add new check and hint for infrastructure configuration issue (detect http -> https redirect, while the daemon is configured to use http).
• This should be manually backported for NC 30 and 31 (because of different tests that are require adjustments).

Thanks to @andrey18106 and the team for the above points!

Describe alternatives you've considered, if relevant

No response

Additional context

No response

Start by tracing the Register daemon and Test Deploy flows, then inspect how OVERRIDE_APP_HOST and Docker Socket Proxy determine the ExApp host for HTTP and HTTPS daemons. Identify the migration and UI validation points needed for remote HTTP setups. Done means the new option, migration, warnings, redirect check, and required backport adjustments are covered.