UserAgent exposed for HTTP requests

[moljac]

Seems like HttpClient has problems, in some cases, with getting info from Maven repositories.

NOTE[s]:

• never experienced this error from local Mac builds
• the problem was detected on CI/CD servers during binderator runs on Mac (never on Windows):

Unhandled exception. System.Collections.Generic.KeyNotFoundException: No version for artifact `accompanist-placeholder-material` with version: `0.30.1`
   at MavenNet.MavenRepository.GetProjectAsync(String groupId, String artifactId, String version)
   at AndroidBinderator.Engine.ProcessConfig(BindingConfig config) in D:\a\_work\1\s\Util\Xamarin.AndroidBinderator\Xamarin.AndroidBinderator\Engine.cs:line 65
   at AndroidBinderator.Engine.BinderateAsync(BindingConfig config) in D:\a\_work\1\s\Util\Xamarin.AndroidBinderator\Xamarin.AndroidBinderator\Engine.cs:line 46
   at Xamarin.AndroidBinderator.Tool.Program.Main(String[] args) in D:\a\_work\1\s\Util\Xamarin.AndroidBinderator\Xamarin.AndroidBinderator.Tool\Program.cs:line 67
   at Xamarin.AndroidBinderator.Tool.Program.<Main>(String[] args)
An error occurred when executing task 'binderate'.
Error: Process xamarin-android-binderator exited with code 134.

MavenNet error after adding unit-test case reveals true cause of the exception/error:

[xUnit.net 00:00:02.12]       
    System.Net.Http.HttpRequestException : 
    Response status code does not indicate success: 403 (Forbidden).

Error/exception occurs ONLY for SOME artifacts (gropuId) - in this case com.google.accompanist group.

Artifacts (repro data - urls) causing exception:

    com.google.accompanist:accompanist-appcompat-theme:0.30.1
    com.google.accompanist:accompanist-placeholder-material:0.30.1

The reason for failures for SOME artifacts, could be behind reverse proxy and database partitioning/shardening
and requests hitting SOME/SPECIFIC HTTP server[s] for those specific packages.

The solution is to add User-Agent to requests, so HttpClient was exposed, so headers can be
manipulated.

[moljac]

/azp run

[jpobst]

Note that the issue here was that Maven Central had a CDN issue where some of their servers were missing the 30.1 versions. I had them flush their CDN for these files and it should be fixed now.

Apparently I didn't bother to save my login for their JIRA, but here's the link if someone wants to create an account:
https://issues.sonatype.org/browse/MVNCENTRAL-8023

> When attempting to access this file:
> [https://repo1.maven.org/maven2/com/google/accompanist/accompanist-placeholder-material/maven-metadata.xml]
>  
> Some of our machines correctly see a version with `<lastUpdated>20230404050249</lastUpdated>` that has `<latest>0.31.0-alpha</latest>`.
> - These machines report an IP address for `repo1.maven.org` of `199.232.192.209` via `nslookup`.
>  
> However some of them retrieve a version with `<lastUpdated>20230323002739</lastUpdated>` that has `<latest>0.30.0</latest>`.
> - These machines report an IP address for `repo1.maven.org` of `151.101.20.209` via `nslookup`.
>  
> If I use a hosts file to manually point a machine that works correctly to the `151.101.20.209` IP address, it receives the incorrect file.
>  
> My guess is this is a stale CDN issue.

Joel Orlina updated MVNCENTRAL-8023:
------------------------------------
    Resolution: Fixed
        Status: Done  (was: To Do)

[moljac]

Note that the issue here was that Maven Central had a CDN issue where some of their servers were missing the 30.1 versions. I had them flush their CDN for these files and it should be fixed now.

I tested few more versions which led me into thinking that it is something with reverse proxy and DB partitioning/shardening.

OK. Let me test AX PRs and if everything is OK we can close this PR.