Let me go in more detail here than is necessary: you probably know most of this - but others might not.
Short answer: Both cookie types are set to expire far, far in the future (10,000 days to be precise). There is no indefinite cookie, so setting them to a future day is the closest thing. Additionally JATOS_IDS_* gets deleted when the study run is finished.
The JATOS_GENERALSINGLE_UUIDS cookie stores the IDs of studies that have been done with the General Single worker. The reason behind is to prevent multiple runs of the same study (which the General Single worker does not allow). Ideally this cookie should never expire. Of course the worker can just go to a different browser or delete the cookie. This is not a safe method to prevent multiple study runs - use Personal Single for this.
Then the JATOS_IDS_* cookies pass on some data from the JATOS server to jatos.js that can be used by the study's JS. Additionally it's needed to request the init data from JATOS for this study run, e.g. study/batch/group session data (basically everything that is too large or sensitive to be put into a cookie). Participants usually run only one JATOS study at the same time in the same browser and this needs only one JATOS_IDS_*. The reason why there are actually up to 10 of those, JATOS_IDS_0 ... JATOS_IDS_9, is that during study development you often want to play around with more then one study run and without necessarily finishing all other runs. And for development of group studies this is actually essential: you can run a group study in the same browser (with up to 10 members). When a study run is properly finished (State FINISHED) the corresponding cookie is removed. Sometimes this does not happen because the study was never properly finished. In those case the cookie stays in the browser until at one point it will be overwritten by a new study run cookie (always the oldest JATOS_IDS_* gets overwritten if there is no empty slot).
I thought about turning the JATOS_IDS_* cookies into 'session' cookies that are automatically deleted when the browser is closed, but there is a use case for keeping them: components that are reloadable (and their study run) can be continued even if a browser was closed and reopened. With the data from the JATOS_IDS_* cookie jatos.js can load the proper data and the study run can continue at least with the same component and with some usage of the batch session even from the exact same point from when the run was left.