docs: clarify troubleshooting performance with Django authentication

Using the builtin Django authentication system on the API server results
in very significant performance degradation. The documentation already
strongy suggests delegating authentication to a load balancer / reverse
proxy but some people might still rely on the default authentication while
experimenting.

The Troubleshooting section hinted that the performance issue
could be due to Django<->database latency, when it is in fact mostly due
to the use of PBKDF2 for password hashing.

doc/source/troubleshooting.rst

@@ -131,7 +131,7 @@ In no particular order, here's high-level advice that have proven to be useful i
 - The built-in Django development server provided by the default offline API client and ``ara-manage runserver`` is simple and convenient but it isn't meant to provide the best scalability and performance
 - The API server should be run as a service with a WSGI application server like gunicorn, uwsgi or mod_wsgi with apache2/httpd
 - There should be a frontend, reverse-proxy or load balancer such as apache, nginx, haproxy or traefik in front of the API server in order to handle TLS termination, caching and authentication
-- When :ref:`enabling authentication <api-security:Authentication and user management>`, consider using ``EXTERNAL_AUTH`` instead of the Django built-in user management to avoid a database lookup performance hit on every query
+- When :ref:`enabling authentication <api-security:Authentication and user management>`, consider using ``EXTERNAL_AUTH`` instead of the Django built-in user management. This will avoid a significant performance hit hashing the password when authentication must be validated against the database backend. (See issue `#283 <https://github.com/ansible-community/ara/issues/283>`_)
 - While SQLite is good and fast enough at a small scale, it has been reported to run into concurrency and locking issues that can make MySQL or PostgreSQL a better option at a larger scale
 - When using MySQL or PostgreSQL, performance can be significantly improved by enabling callback multi-threading by setting ``ARA_API_CLIENT=http`` and ``ARA_CALLBACK_THREADS=4``
 - When using MySQL or PostgreSQL, set :ref:`api-configuration:ARA_DATABASE_CONN_MAX_AGE` to a value >= ``60`` to allow database connections to be re-used until the specified timeout, avoiding the overhead of closing and opening connections for every query