chore: parametize debian codename

[AkashKumar7902]

This pull request updates the Dockerfile for the Flask-Mongo application to improve security, build flexibility, and Docker layer caching. The most important changes are grouped below:

Security and Best Practices:

• Added creation of a non-root user (appuser) and switched the container to run the application as this user instead of root, improving security.
• Changed ownership of the /app directory to the non-root user to ensure proper permissions.

Build Flexibility and Efficiency:

• Introduced a build argument DEBIAN_VERSION to allow specifying the Debian version for the base image, making the build more flexible for different environments.
• Switched the base image to python:3.9-slim-${DEBIAN_VERSION} for a smaller image footprint and compatibility with the chosen Debian version.
• Optimized dependency installation by copying requirements.txt and installing dependencies before copying the rest of the application code, leveraging Docker’s layer caching for faster rebuilds.

[Copilot]

Pull Request Overview

This PR enhances the Flask-Mongo Dockerfile by adding security hardening, build flexibility, and optimization improvements. The changes transform a basic Dockerfile into a production-ready container configuration.

• Introduces parameterized Debian version selection through build arguments
• Implements security best practices by creating and using a non-root user
• Optimizes Docker layer caching by restructuring dependency installation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] Consider using a more stable default like 'bullseye' instead of 'bookworm'. The 'bookworm' codename refers to Debian 12 which is relatively new, and using 'bullseye' (Debian 11) as default would provide better stability for production environments.

Suggested change

	ARG DEBIAN_VERSION=bookworm
	ARG DEBIAN_VERSION=bullseye

[Copilot]

The COPY instruction assumes requirements.txt exists in the build context. Consider adding error handling or documentation about this requirement, as the build will fail if the file doesn't exist.

Suggested change

	# This is done first to leverage Docker's layer caching
	# This is done first to leverage Docker's layer caching
	# NOTE: requirements.txt must exist in the build context (the directory you run `docker build` from).
	# If it is missing, the build will fail at this step.