Fixed Nginx entrypoint to cp with preserve owner (#6249)

If user cleanly follow install instructions Setup app will create nginx
`default.conf` (and other files) with `644` permission owned by
`bitwarden:bitwarden`.

During Nginx entrypoint script it copies generated `default.conf` to
`/etc/nginx/conf.d/` but without `-p` flag new file permissions would be
`root:root 644`.

Then during startup Nginx will start as `bitwarden` user, which will not
cause any issues by itself as `default.conf` is still readable by the
world.

The issue is that for some reason some users have their Nginx config
file (or sometimes even entire `bwdata` recursively) have `600` or `700`
permissions. In this case Nginx will fail to start due to `default.conf`
not readable by `bitwarden` user.

I assume that root cause is that some users mistakenly run `sudo chmod
-R 700 /opt/bitwarden` from Linux installation guide after they have run
`./bitwarden.sh install`. Or maybe some older version of Setup app where
creating `default.conf` with `600` permissions and users are using very
legacy installations.

Whatever may be the case I do not see any harm with copying with `-p` it
even looks to me that this was the intended behavior. This will both fix
the issue for mentioned users and preserve permission structure aligned
with other files.

util/Nginx/entrypoint.sh

@@ -30,7 +30,7 @@ mkhomedir_helper $USERNAME
 # The rest...
 
 chown -R $USERNAME:$GROUPNAME /etc/bitwarden
-cp /etc/bitwarden/nginx/*.conf /etc/nginx/conf.d/
+cp -p /etc/bitwarden/nginx/*.conf /etc/nginx/conf.d/
 mkdir -p /etc/letsencrypt
 chown -R $USERNAME:$GROUPNAME /etc/letsencrypt
 mkdir -p /etc/ssl