feat: use JWT bundle's command to create keys

Creation of directory and files is now covered by
lexik/jwt-authentication-bundle's command.

This somewhat causes the directory/file location to pop up out of
nowhere in the subsequent permission change (`setfacl`). That could be
avoided by extracting JWT_SECRET_KEY and JWT_PUBLIC_KEY from api's
`.env` file (section maintained by the bundle) but it adds bloat without
apparent benefit.

The previously documented behaviour was closer to using the
`--overwrite` option on the command, but I doubt it is in the user's
best interest in a starter guide. Using `--skip-if-exists` would make
some sense, but bailing feels like the sane option – the user obviously
touched this area before and should be made aware.

Resolves #1446

Co-authored-by: Kévin Dunglas <kevin@dunglas.fr>

Author: wiese

core/jwt.md

@@ -24,19 +24,15 @@ Then we need to generate the public and private keys used for signing JWT tokens
 docker-compose exec php sh -c '
     set -e
     apk add openssl
-    mkdir -p config/jwt
-    jwt_passphrase=${JWT_PASSPHRASE:-$(grep ''^JWT_PASSPHRASE='' .env | cut -f 2 -d ''='')}
-    echo "$jwt_passphrase" | openssl genpkey -out config/jwt/private.pem -pass stdin -aes256 -algorithm rsa -pkeyopt rsa_keygen_bits:4096
-    echo "$jwt_passphrase" | openssl pkey -in config/jwt/private.pem -passin stdin -out config/jwt/public.pem -pubout
+    php bin/console lexik:jwt:generate-keypair
     setfacl -R -m u:www-data:rX -m u:"$(whoami)":rwX config/jwt
     setfacl -dR -m u:www-data:rX -m u:"$(whoami)":rwX config/jwt
 '
 ```
 
 Note that the `setfacl` command relies on the `acl` package. This is installed by default when using the API Platform docker distribution but may need be installed in your working environment in order to execute the `setfacl` command.
 
-This takes care of using the correct passphrase to encrypt the private key, and setting the correct permissions on the
-keys allowing the web server to read them.
+This takes care of keypair creation (including using the correct passphrase to encrypt the private key), and setting the correct permissions on the keys allowing the web server to read them.
 
 Since these keys are created by the `root` user from a container, your host user will not be able to read them during the `docker-compose build caddy` process. Add the `config/jwt/` folder to the `api/.dockerignore` file so that they are skipped from the result image.