Various fixes/improvements

[Avery-Dunn]

This PR handles a number of small issues from our backlog:

• [Feature Request] Remove x-client-cpu #726 : Removes an unnecessaries telemetry header
• [Bug] HttpListener (HTTP-Dispatcher thread) stays alive for 120 seconds after client timeout occurs #741 : When a future was cancelled it shut down the relevant thread, however Java 9+ introduced timeout behavior that our code didn't consider so threads would continue through a timeout. We now check for exceptions (such as TimeoutException) as well as cancellations
• Change log level from info to debug for AcquireTokenSilentSupplier #751 : Lowers the log level for successful cache lookup from 'info' to 'debug' to keep per-request logs more useful
• Errors is logged and thrown at the same time in AuthenticationResultSupplier resulting in handled exceptions still being logged as errors #662 : Reduce verbosity of logs produced right before an exception, and avoid logging at an 'error' level if an exception will be thrown anyway

[bgavrilMS]

Timeout in interactive flow is not something MSALs do and it's not something we ask app dev to do either. It can take a really long time to perform auth - e.g. I was just asked to MFA and then to change password.

But anyway, it looks like this is based on public API, so it's fine.

[Avery-Dunn]

For interactive flow we have a timeout parameter that would cause this loop to end after a default 120 seconds:

microsoft-authentication-library-for-java/msal4j-sdk/src/main/java/com/microsoft/aad/msal4j/InteractiveRequestParameters.java

Line 100 in ebdd4fc

private int httpPollingTimeoutInSeconds = 120;

This ended up being kind of a weird situation. In Java 8 there wasn't really a timeout option for ending a future (there was a timeout for waiting for the result), however in Java 9 they started introducing methods for completing the future after a timeout. Since we target Java 8 as a minimum but also want to support newer versions, this means

• Java 8 customers need that httpPollingTimeoutInSeconds as a timeout to end the interactive flow
• Java 9+ customers can use the newer timeout methods in Java's CompletableFuture API, and will be confused if MSAL doesn't follow those timeouts

[bgavrilMS]

Could you add a comment on what "isDone" is doing here? I think it returns true when cancel() is called, or when the future completes with success?

[Avery-Dunn]

isDone returns true when a future is cancelled (like the current behavior), plus when it completes normally or with an exception. In other words, isDone covers any situation where we can't return the auth result, and there's no point in continuing this loop.

By only checking isCancelled there were scenarios where thread spun off to complete futures could continue to pointlessly run (such as when the app developers sets a timeout in the future #741).