Unfortunately I agree with you that I don’t see a method to do a “rolling restore”. A replica set can be used to perform a rolling maintenance, but a restore is a different matter entirely since it is a contradiction of what a replica set is.
Let me explain: all nodes in a replica set should contain the same data, since the main function of a secondary is to be able to take over the primary’s function at a moment’s notice. Therefore, a secondary that has a different data than the primary is by definition not a secondary anymore, so not really part of the replica set anymore.
So it’s not possible to do a rolling restore without downtime (at least when using filesystem snapshot). It is entirely possible if you have a backup of that specific database, though, as all you need to do to restore it is to insert that database into the primary again, so a likely scenario is:
Restore the snapshot to a new standalone server, unconnected to the replica set
Dump the desired database using e.g. mongodump
Restore the database to the replica set’s primary
The secondaries should replicate the restored database
Since filesystem snapshot takes a snapshot of the volume, I don’t believe it’s possible to recover a specific content of the filesystem (database or otherwise) unless the snapshot was restored first.