Fix to hide Http MessageHandler cleanup messages

[Omotola]

Based on these threads Stack Overflow, Github, It seems the multiple cleanup messages are default behavior as it waits to clean up the message handler resources. The suggested thing to do is hide the messages in the logs if we don't want to see them.

[codecov]

Codecov Report

Merging #816 (67d2fbf) into main (4560a88) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #816   +/-   ##
=======================================
  Coverage   75.84%   75.84%           
=======================================
  Files         240      240           
  Lines        9979     9979           
=======================================
  Hits         7569     7569           
  Misses       2410     2410           

[melotic]

This means that there's a client/message handler that's been expired, but someone is still holding a reference to it. You can analyze what's keeping it alive by capturing a memory dump.

Do we dispose all instances of the HTTPClient? Why does the old pip detector work fine but this not?

I'm not sure this is the right solution but instead just masking the logs.

[Omotola]

Do we dispose all instances of the HTTPClient? Why does the old pip detector work fine but this not?

@melotic Yeah, the httpclient is only created using httpclientfactory in the SimplePypiClient, and its disposed after. The original pip detector doesn't use httpclientfactory, it manually creates the httphandler and httpclient. Jamie had mentioned that doing it that way would result in resources not being cleaned up properly afterwards. He suggested using httpclientfactory for the simplepipdetector cause it uses dependency injection to inject the httpclient, and handles the cleanup by itself.

Also if you scroll down to the end of that github issue you quoted, you'll see where they concluded that cleanup message loop is by design. I also found another article here that explains that by design httpclientfactory expires handlers after 2 minutes of no longer being in use and adds them to an expired queue, and then there is a cleanup job that checks that queue and has a timer that checks every 10 seconds if the handler has been garbage collected so it can cleanup other internal resources (i.e socket connections).
In the logs we see in our builds you will notice there is the expiration message of the one handler

and then the consequent cleanup loop at 10 second intervals which is just waiting for the handler to be GC

[melotic]

this will need to replicated in internal