This would currently help to stop/restart fast swh-worker services (as currently deployed in our stack).
That would also help with elastic workers to downscale fast (if need be) or to time frame some loaders. 
As it is not currently the case, a stop or restart is as fast as the current
ingestion ongoing will take. For some hg or git repositories, that can take time (hours, well
there is now a timeout but still).
This could be implemented for example with a signal handler to react to the warm shutdown
signal. For loaders, the signal handler would do a partial snapshot with what it had ingested so far.
For listers, it can flush its visited state for the ongoing forge (on incremental).
 Related to T3592 (but as described not only that)