Make stacks metadata for dependencies dependent on version

[fg-j]

Summary

In the process of trying to support Jammy Jellyfish in Paketo we need to test whether existing dependencies are compatible with Jammy. I've found that .NET 3.1 is not compatible with the Jammy Jellyfish, but .NET 6.0 is. For this reason, the stacks metadata for .NET dependencies must be more flexible; it must depend on the version of the dependency, not just the ID. I've updated the workflow template data schema and the test-and-upload-metadata.yml workflow to support this use case.

While this PR will ultimately generate a diff in all dependencies' *-test-and-upload-metadata.yml, it's intended not to change the behaviour of the metadata upload step EXCEPT for .NET dependencies; the output metadata for all other dependencies should look exactly the same. It also sets us up to add version constraints to other dependencies+stacks as needed, as we roll out Jammy support.

Use Cases

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[sophiewigmore]

@fg-j Just tried this out and it works as expected. I think this is a fine addition to the dep-server. My main question around this addition is timing. Are you planning to get .NET Core onto Jammy before the dependency management update plan goes into effect?

If so, are you planning to add support for .NET Core 3.1 to run on Jammy? Will this involve adding another jammy-flavoured version of 3.1 to the dep-server and processing it differently? If that's the case, it might make more sense to wait but I'm interested to hear your thought process!

[fg-j]

My understanding is that we want to get as many buildpacks on Jammy as possible, as soon as possible. So I hope .NET lands on Jammy before dependencies work finishes.

I don't see us supporting .NET 3.1 on Jammy. .NET 3.1 depends on a version of OpenSSL (1.x) that we don't currently install on our jammy stacks; OpenSSL 3 is the standard version to install on Jammy. I doubt that we want to roll back to OpenSSL 1.x or install two competing versions of OpenSSL, especially since .NET 3.1 goes EOS at the end of this year.

I'm hoping that this change enables us to migrate as many buildpacks as we can onto Jammy without having to change our compilation process. However, given the deps work, I hope this change will be short-lived!

[sophiewigmore]

@fg-j thanks for the context- totally understood. We won't be supporting a Jammy-compatible version of .NET 3.1 dependencies which makes life much easier!

One last thing of note - this change will apply to new versions that are discovered only. If we want to support Jammy for every 6.0.* version in the most recent version of the .NET buildpacks we will need to do some metadata updating down the line. I can help out with this if needed!