Make sure http connections have a timeout and throw an exception

[ehoogerbeets]

• We were attempting to use the Basic tunneling scheme to talk to webproxy, but the JDK turns it off by default, so queries through our webproxy server were silently hanging
• This PR puts a 30 second timeout on the http connection and throws an exception that makes it into the logs so that we aren't wondering what happened. No more silent failure!

[wadimw]

I think we shouldn't implicitly mess with JDK's security defaults. It makes sense to add -Djdk.http.auth.tunneling.disabledSchemes= to our internal deployment launch args (since this is an isolated environment), but not here.

Since you didn't provide too much context, please confirm if Cursor-assisted justification of your PR is correct:

• proxy on our deployment requires Basic auth (isolated env, so not a security problem)
• Mojito's Box client already uses Basic auth (https://github.com/box/mojito/blob/upstream-patched/webapp/src/main/java/com/box/l10n/mojito/boxsdk/BoxAPIConnectionProvider.java#L69), because Box Java SDK v4 actually sidesteps JDK Authenticator (https://github.com/box/box-java-sdk/blob/831df7788148c7b931a99b77cd3c7a2657349432/src/main/java/com/box/sdk/BoxAPIConnection.java#L755-L759) - which is why this wasn't a problem before
• JDK for reasons unknown doesn't throw an exception if it can't set up a connection due to disabled auth schemes, instead it just hangs indefinitely, which means the AI translate/review jobs hang too and there is no error message to diagnose the problem

If so, I think this PR should be converted to add a connection timeout to the HttpClient.Builder in OpenAIHttpClientFactory (with a comment that explains a possible reason for this hangup).

[ehoogerbeets]

We originally found this problem by running the AiTranslateServiceTest tests which are integration tests. These are skipped if the proxy information is missing in the application.properties. When we provided our proxy credentials and ran again, sure enough, we get the silent hang. We eventually figured out it was because of the Basic scheme disablement.

I originally thought it was the JDK side that wanted to talk to the webproxy server with Basic sheme. However, it turns out that it is actually our proxy server that is requiring it.

SO, we're going to update this so that you can put something like "useBasic" in the proxy settings in application.properties and it will re-enable Basic by itself. That way, it stays off by default, and you can explicitly turn it on again if your environment requires it.

Also, we'll put the timeout in for safety.

[wadimw]

Is there a better/more Java-idiomatic way to trigger failure than hardcoding a specific URL? maybe like a mock connection or something

[ehoogerbeets]

Cursor says:

192.0.2.1 is not a normal local/LAN address.

It comes from TEST-NET-1 (192.0.2.0/24), reserved by RFC 5737 for documentation and examples. IANA marks that block as special-use; it must not be routed on the public Internet, and the RFC says these blocks are not for local use. Operators are expected to treat them as non-routable / filter them.

[ehoogerbeets]

I updated the comment above it to make it more clear what this IP address is all about and give the link to the RFC for it.

[wadimw]

This is also superceded by #1070 right?

[ehoogerbeets]

Yes, I'll close it.