Update `dotnetapp` and `aspnetapp` samples to non-root

[richlander]

We're considering a plan to make all the images we publish as non-root-capable (as a turnkey experience). That would be a significant change in security posture and enablement for users. At least in the .NET space, it would change the conversation on secure hosting of apps in containers.

We've always thought of the samples we ship as a sort of technology demonstration. It's much easier to understand what .NET in containers (or just containers generally) is all about if you can quickly try a sample/demo. Clearly, if we're adopting non-root as a pillar of our offering, it makes sense to publish the samples as non-root. We want the samples to be our best mainline opinionated offering.

What does that mean?

• Samples would be configured to a non-root user
• The aspnetapp samples would not longer listen on port 80 but on a non-privileged port, like 5000 or 8080.
• Anyone relying on the samples that was relying on the images being configured with the root user or to listen on port 80 would be broken.

We're happy for folks to use these images. If you are using the aspnetapp one in particular, you should configured the port you want use yourself with ASPNETCORE_URLS and ensure you use a non-privileged port. We know of some folks using this image for testing, so this concern isn't theoretical.

We can make this change in steps:

• Publish an aspnetapp-nonroot image, per this proposal.
• Give folks an opportunity to test it and provide feedback.
• Publish the non-root image as aspnetapp after two months (assuming no reason to do otherwise).
• Delete the aspnetapp-nonroot image from the registry.

[mthalman]

We'll implement these changes as part of .NET 8 release when non-root-capable .NET images are planned.

[richlander]

This work is now ready to go.

[MichaelSimons]

This is related to if not a duplicate of what I intended with #1772.

[mthalman]

Closing this in favor of #1772, which is essentially proposing the same thing. Thanks for the detail you've provided in this, @richlander. We'll be referring to it.