Reorganize the tap result link aqavit_tapresult_link

[sophia-guo]

Is your feature request related to a problem? Please describe.
Currently the marketplace test result link is designed per each binary (for example: "aqavit_results_link" : "https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.6%2B10/OpenJDK17U-jdk_x64_linux_hotspot_17.0.6_10.tap.zip","). As discussed and implemented in Ensure we are pushing AQAvit TAP files to the binaries repository for each release there will only be one final AQAvit TAP file per release ( for example https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.6%2B10/AQAvitTapFiles.tar.gz), most often for now the tap file will be uploaded to the release repo after all tests are triaged. We'd like to update the api query https://api.adoptium.net/v3/assets/feature_releases/${version}/ga?page_size=50&vendor=eclipse to get the aqavit_tapresult_link if AQAvitTapFiles.tar.gz is available.

Describe the solution you'd like
With that enabled and PR like https://github.com/adoptium/api.adoptium.net/compare/marketplace...sophia-guo:marketplace?expand=1 Marketplace-data can be auto updated by workflow https://github.com/adoptium/marketplace-data/blob/main/.github/workflows/temurin-updater.yml

Describe alternatives you've considered
Or any other solutions suggested, maybe the issue #34?

Additional context
Add any other context or screenshots about the feature request here.

[sophia-guo]

@johnoliver @tellison any suggestion?

[johnoliver]

@sophia-guo wrt moving aqavit_results_link, I think the issue here will be, is the decision to do 1 tap file for all binaries in a release specifically an Adoptium decision or something that would be true for ALL marketplace vendors. For instance Dragonwell appears to show a tap file for each binary:

https://github.com/dragonwell-releng/dragonwell-adoptium/blob/master/json/8/jdk_8u345b01.json

So moving it to the release would prevent them from doing this. Although the current behaviour will result in redundant entries for Adoptiums releases, that is probably preferable to restricting other vendors ability to do per binary tap files.

WRT adding aqavit_results_link to the adoptium api, we can certainly do that, if you are certain that Adoptium will remain doing one tap file per release, then we can put it on the Release object in the Adoptium API. Are we sure that it will remain 1 per release, since once we add it to the Release object we will not be able to alter that till api v4.

[sophia-guo]

@smlambert what's your suggestion regarding @johnoliver 's concerns #33

[smlambert]

My thought is that we simply need to update our marketplace-data json file for temurin to link to the consolidated AQAvitTap.tar.gz file for all aqavit_results_link entries. SInce it contains TAP files for all platforms, it is sufficient to provide for each platform entry. It is perfectly fine that the contents of the file is a superset of all platforms.

So, in the example case, https://github.com/adoptium/marketplace-data/blob/main/17/jdk_17_0_6_10.json, all 22 aqavit_results_link would link to https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.6%2B10/AQAvitTapFiles.tar.gz