To find the transactions between restart_lsn and confirmed_lsn you can see the wal using pg_dump and examine the contents.
For the question how restart_lsn is updated the answer would be, on high level it depends on confirmed_flush_lsn provided by client.Unless and until client confirms we cannot move restart_lsn to some value.Now the question would be exactly to what value the restart_lsn is updated? the answer is there is something called as reorderBufferTxn structure in code where it stores required changes to decode also other meta information about first_lsn/start_lsn of a transaction. Walsender while reading WAL for decoding he maintains a candidate_restart_lsn which is the minimum of all transactions in reorderBuffer(map which contains all reorderbufferTxns) at that point of time.Now whenever client sends some feedback he will make sure that if candidate_restart_lsn <= feedback_lsn if true then he will update the restart_lsn=candidate_restart_lsn. This is very low level but in short we can say restart_lsn is updated based on 2 things
1.It depends on the confirmed_flush_lsn
2.oldest running txn at that point of time to update the candidate_restart_lsn and later based on feedback we update the actual slot's restart_lsn with candidate_restart_lsn