Add encryption secret to configuration

Not setting an encryption-secret can cause unexpected behaviour. Each restart, even from hot reload, will pick a new encryption secret otherwise, invalidating existing logins. This is a very annoying behaviour during development.

docs/src/main/asciidoc/security-oidc-code-flow-authentication-tutorial.adoc

@@ -169,6 +169,7 @@ quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
 quarkus.oidc.client-id=frontend
 quarkus.oidc.credentials.secret=secret
 quarkus.oidc.application-type=web-app
+quarkus.oidc.token-state-manager.encryption-secret=secret2
 quarkus.http.auth.permission.authenticated.paths=/*
 quarkus.http.auth.permission.authenticated.policy=authenticated
 ----
@@ -177,6 +178,8 @@ This is the simplest configuration you can have when enabling authentication to
 
 The `quarkus.oidc.client-id` property references the `client_id` issued by the OIDC provider, and the `quarkus.oidc.credentials.secret` property sets the client secret.
 
+The `quarkus.oidc.token-state-manager.encryption-secret` enables the default token state manager to encrypt the user tokens in a browser cookie. If this key is not defined, Quarkus uses a random key. A random key causes existing logins to be invalidated either on application restart or in environment with multiple instances of your application. Alternatively, encryption can also be disabled by setting `quarkus.oidc.token-state-manager.encryption-required` to `false`. However, you should disable secret encryption in development environments only.
+
 The `quarkus.oidc.application-type` property is set to `web-app` to tell Quarkus that you want to enable the OIDC authorization code flow so that your users are redirected to the OIDC provider to authenticate.
 
 Finally, the `quarkus.http.auth.permission.authenticated` permission is set to tell Quarkus about the paths you want to protect.