Permission denied when using external mounts

Disclaimer: This is a copy of https://github.com/bitwarden/server/issues/2989, since the Docker part moved to this repo

### Steps To Reproduce
1. Install according to official documentation
2. Use an external storage mount for the data directory /etc/bitwarden. Examples:
i. Official Docker docs for NFS: https://docs.docker.com/storage/volumes/#create-a-service-which-creates-an-nfs-volume
ii. EFS Volume on AWS Fargate: https://docs.aws.amazon.com/AmazonECS/latest/userguide/efs-volumes.html
Expected Result
Regular working Service with a highly available and easy to backup storage solution in the background.

### Actual Result
The logs show a "permission denied" error when trying to set the permissions for /etc/bitwarden. This happens in the unified and the regular containers.
The exact line of code producing the error is for the regular installation this https://github.com/bitwarden/server/blob/master/src/Admin/entrypoint.sh#L33 and for the unified this https://github.com/bitwarden/server/blob/master/docker-unified/entrypoint.sh#L97.

After some investiagation the underlying problem seems to be that the application user is created in the entrypoint.sh script and thus the /etc/bitwarden directory is owned by root:root during the container creation when the mount is happening. Changing permissions to a mounted directory is not possible afterwards, thus the application does not have permissions to /etc/bitwarden during runtime and does not work.

### Screenshots or Videos
No response

### Additional Context
Best practice by Docker seems to be to create the user with an explicit UID/GID during the image creation and not during container startup. Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user
A change of this explicit UID/GID should then not be done in the entrypoint script but utilizing a remap as suggested by Docker: https://docs.docker.com/engine/security/userns-remap/

### Build Version
https://github.com/bitwarden/server/commit/8d9ca424a1ec2079cc2508be5c23a4883987ea69-dirty and 2023.4.3

### Environment
Self-Hosted

### Environment Details
Tested on various Setups including:

* Server installation on Ubuntu LTS 22.04 and 20.04 using an external NFS storage mount.
* AWS ECS Fargate installation with and EFS share

### Issue Tracking Info

- [x] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

Read src/Admin/entrypoint.sh at line 33 and docker-unified/entrypoint.sh at line 97, then reproduce the failure with an external NFS or EFS mount under /etc/bitwarden. Check the Docker user and permission behavior during image creation and container startup. Done means both regular and unified containers start and operate with an external mount without a permission-denied error.

Written by the indexing model from the issue text.