When creating many users with the batch user creation feature, the web server may return a time out before the application responds.

To make the solution more robust, I think we should do something along these lines (this is not an exhaustive plan, further research may be needed):

• Move the logic which generates the users to a background celery task.
• Add some kind of status field, this could be a simple boolean, eg: completed, defaulting to False.
• The UI must be updated to clearly indicate the operation is being processed and not complete yet, we shall hide/disable some aspects if needed to avoid users tampering with the data. We can use a warning header (like when using the django message framework, but overriding the template instead of relying on the message framework which is unpractical here due to the need of passing around the HTTP request object).
• Once the import/generation operation is completed, we flag the new field as True.
• In the change_form template, we add websocket JS logic to reload the page when the operation has completed, however, if we detect that nobody is browsing the page anymore (eg: we can program the JS to send an acknowledgment to the server if needed), we can send a notification to all the org admins and superusers with openwisp-notifications to let them know the operation has completed. This point happens only when running in async mode.
• We must update the REST API to take this flow into account, eg: add the new field, do not allow any delete operation while the operation is being completed.
• REST API: let's make sure the batch object cannot be edited once created (in the same as the admin works)
• Admin: do not allow to delete until the operation is completed
• We must ensure the new flow works well also for small batches that would have worked well with the current synchronous code, maybe we can use the async flow only for batches that are larger than a certain amount of users, like 15 and make this configurable, eg: OPENWISP_RADIUS_BATCH_ASYNC_THRESHOLD.