Is your proposal related to a problem?

Yes, described in discussion #10242.

Describe the solution you'd like

Add to remote schema configuration the following fields:

• HTTPS_PROXY
• HTTP_PROXY
• WSS_PROXY
• WS_PROXY

They control how hasura connects to a remote schema:
1/ HTTPS_PROXY, HTTP_PROXY for queries and mutations
2/ WSS_PROXY, WS_PROXY for subscriptions

Variables 1/ are typically used by curl, wget, Python requests.

Variables 2/ would be the same for wss:// and ws:// flows.
Though most corp proxies will not allow that traffic anyway it shouyld be possible to configure it.

If these values are not set, then no proxy is used for the connection to the remote schema.

The NO_PROXY field is not useful as the absence of *_PROXY has the same effect.

Describe alternatives you've considered

Alternatively the fields above could be infered from the environment variables with the same name for all remote schemas.
But bad design, I think, as some remote schemas would be accessible through a proxy only, and other without only.
This is typically the case when an hasura graphql engine deployed on a corp premises has remote schemas inside (private) and outside (public) the corp network.