fix: Enable selecting the '.NET 6 on AL2023' platform when deploying to Elastic Beanstalk on Linux

[ashovlin]

Issue #, if available: #806 (I had tested this quickly when talking to @shruti0085 internally about this issue)

Description of changes:

This widens the string we use to filter Beanstalk Platform options when deploying to Linux, to include the new ".NET 6 on AL2023" platform that was released in October.

Considerations:

• The sort order we're getting back from the service call is what I think we want, so didn't introduce custom sorting like we have for Windows here:

  aws-dotnet-deploy/src/AWS.Deploy.Orchestration/Data/AWSResourceQueryer.cs

  Line 627 in 03abb11

  public static void SortElasticBeanstalkWindowsPlatforms(List<PlatformSummary> windowsPlatforms)

• Per the docs, the new platform only has .NET 6 installed. However our Beanstalk recipes still allow netcoreapp3.1 or greater:
  

  aws-dotnet-deploy/src/AWS.Deploy.Recipes/RecipeDefinitions/ASP.NETAppElasticBeanstalkLinux.recipe

  Line 36 in 03abb11

  "AllowedValues": [ "netcoreapp3.1", "net5.0", "net6.0", "net7.0", "net8.0" ]

  
  Deploying an application with an older target (in this case .NET 5) to the new AL2023 platform results in:

Dec  5 22:10:04 ip-172-31-83-112 web[2147]: You must install or update .NET to run this application.
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: App: /var/app/current/ASPNet5.dll
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Architecture: x64
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Framework: 'Microsoft.AspNetCore.App', version '5.0.0' (x64)

However this is true even for the recent AL2 platform versions as well. Unsure if we want to unblock AL2023 initially with this, then better handle the compatibility between the application being deploying and the specific selected platform later? Or try to tackle both issues together

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a8785c3) 61.44% compared to head (86248a3) 61.44%.
Report is 1 commits behind head on dev.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #807   +/-   ##
=======================================
  Coverage   61.44%   61.44%           
=======================================
  Files         277      277           
  Lines       10659    10659           
  Branches     1484     1484           
=======================================
  Hits         6549     6549           
  Misses       3568     3568           
  Partials      542      542           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ashovlin]

Deploying an application with an older target (in this case .NET 5) to the new AL2023 platform results in:

Dec  5 22:10:04 ip-172-31-83-112 web[2147]: You must install or update .NET to run this application.
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: App: /var/app/current/ASPNet5.dll
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Architecture: x64
Dec  5 22:10:04 ip-172-31-83-112 web[2147]: Framework: 'Microsoft.AspNetCore.App', version '5.0.0' (x64)

However this is true even for the recent AL2 platform versions as well. Unsure if we want to unblock AL2023 initially with this, then better handle the compatibility between the application being deploying and the specific selected platform later? Or try to tackle both issues together

We discussed this in today's GitHub triage meeting with @normj , we're comfortable NOT closing this gap at this point. We expect users to be moving off of .NET Core 3.1 and .NET 5 anyway.