CLI: Always do hard reset in verdi daemon restart (#6317)

By default, `verdi daemon restart` would perform a "soft" restart of the
daemon, meaning that just the daemon workers would be restarted and not
the daemonizer process itself. The original reasoning was that a full
reset was usually not necessary and would take more time than a soft
restart.

However, exactly when a full restart is necessary is not easy to define
and so by default users would be recommended to run with the `--reset`
flag to perform a full restart. In practice, this would add complexity
for little gain because the second extra it takes to perform a full
restart is negligible in most situations.

Therefore, the `--reset` flag, as well as the `--no-wait` and `--timeout`
flags which only make sense in the case of a soft reset, are deprecated
and the command now always performs a full restart.

docs/source/howto/faq.rst

@@ -85,7 +85,7 @@ For example, go to the directory that contains the file where you defined the pr
 
     $ echo "export PYTHONPATH=\$PYTHONPATH:$PWD" >> $HOME/.bashrc
     $ source $HOME/.bashrc
-    $ verdi daemon restart --reset
+    $ verdi daemon restart
 
 .. _how-to:faq:caching-not-enabled:
 

docs/source/howto/plugin_codes.rst

@@ -453,7 +453,7 @@ Finally instead of running your calculation in the current shell, you can submit
 
 .. code-block:: console
 
-    $ verdi daemon restart --reset
+    $ verdi daemon restart
 
 * Update your launch script to use:
 

docs/source/howto/plugins_install.rst

@@ -27,11 +27,11 @@ For example, if the code is available through a Git repository:
 
 .. warning::
 
-    If your daemon was running when installing or updating a plugin package, make sure to restart it with the ``--reset`` flag for changes to take effect:
+    If you installed or updated a plugin package while your daemon was running, be sure to restart it so that the changes take effect:
 
     .. code-block:: console
 
-        $ verdi daemon restart --reset
+        $ verdi daemon restart
 
 To verify which plugins are currently installed, use the command:
 

docs/source/howto/workchains_restart.rst

@@ -185,7 +185,7 @@ As you can see the work chain launched a single instance of the ``ArithmeticAddC
 
     .. code-block:: bash
 
-        $ verdi daemon restart --reset
+        $ verdi daemon restart
 
     Indeed, when updating an existing work chain file or adding a new one, it is **necessary** to restart the daemon **every time** after all changes have taken place.
 
@@ -249,7 +249,7 @@ When submitting or running the work chain using namespaced inputs (``add`` in th
 
     .. code-block:: bash
 
-        $ verdi daemon restart --reset
+        $ verdi daemon restart
 
 
 Customizing outputs

src/aiida/cmdline/commands/cmd_daemon.py

@@ -217,24 +217,27 @@ def stop(ctx, no_wait, all_profiles, timeout):
 def restart(ctx, reset, no_wait, timeout):
     """Restart the daemon.
 
-    By default will only reset the workers of the running daemon. After the restart the same amount of workers will be
-    running. If the `--reset` flag is passed, however, the full daemon will be stopped and restarted with the default
+    The daemon is stopped before being restarted with the default
     number of workers that is started when calling `verdi daemon start` manually.
 
     Returns exit code 0 if the result is OK, non-zero if there was an error.
     """
     if reset:
-        # These two lines can be simplified to `ctx.invoke(start)` once issue #950 in `click` is resolved.
-        # Due to that bug, the `callback` of the `number` argument the `start` command is not being called, which is
-        # responsible for settting the default value, which causes `None` to be passed and that triggers an exception.
-        # As a temporary workaround, we fetch the default here manually and pass that in explicitly.
-        number = ctx.obj.config.get_option('daemon.default_workers', ctx.obj.profile.name)
-        ctx.invoke(stop)
-        ctx.invoke(start, number=number)
-        return
-
-    echo.echo('Restarting the daemon... ', nl=False)
-    execute_client_command('restart_daemon', wait=not no_wait, timeout=timeout)
+        echo.echo_deprecated(
+            '`--reset` flag is deprecated. Now, `verdi daemon restart` by default restarts the full daemon.'
+        )
+    if no_wait:
+        echo.echo_deprecated('The `--no-wait` flag is deprecated and no longer has any effect.')
+    if timeout is not None:
+        echo.echo_deprecated('The `--timeout` option is deprecated and no longer has any effect.')
+
+    # These two lines can be simplified to `ctx.invoke(start)` once issue #950 in `click` is resolved.
+    # Due to that bug, the `callback` of the `number` argument the `start` command is not being called, which is
+    # responsible for settting the default value, which causes `None` to be passed and that triggers an exception.
+    # As a temporary workaround, we fetch the default here manually and pass that in explicitly.
+    number = ctx.obj.config.get_option('daemon.default_workers', ctx.obj.profile.name)
+    ctx.invoke(stop)
+    ctx.invoke(start, number=number)
 
 
 @verdi_daemon.command(hidden=True)

src/aiida/cmdline/commands/cmd_rabbitmq.py

@@ -255,7 +255,7 @@ def cmd_tasks_revive(processes, force):
 
     \b
         1. Does ``verdi status`` indicate that both daemon and RabbitMQ are running properly?
-           If not, restart the daemon with ``verdi daemon restart --reset`` and restart RabbitMQ.
+           If not, restart the daemon with ``verdi daemon restart`` and restart RabbitMQ.
         2. Try ``verdi process play <PID>``.
            If you receive a message that the process is no longer reachable,
            use ``verdi devel rabbitmq tasks revive <PID>``.

src/aiida/engine/processes/control.py

@@ -73,7 +73,7 @@ def revive_processes(processes: list[ProcessNode], *, wait: bool = False) -> Non
     Warning: Use only as a last resort after you've gone through the checklist below.
 
         1. Does ``verdi status`` indicate that both daemon and RabbitMQ are running properly?
-           If not, restart the daemon with ``verdi daemon restart --reset`` and restart RabbitMQ.
+           If not, restart the daemon with ``verdi daemon restart`` and restart RabbitMQ.
         2. Try to play the process through ``play_processes``.
            If a ``ProcessTimeoutException`` is raised use this method to attempt to revive it.