Short version
What you are asking for does not exists in the main-line Linux kernel, and for good technical reasons the kernel developers are not likely to add it.
After a resume the kernel already knows exactly which virtual pages are resident and which ones are still on the swap device – that information is part of the hibernate image.
What it does ​not​ do is read those swapped-out pages back into RAM “just in case”. If a process touches one of them the normal demand-paging machinery pulls it back, and that is the disk activity you notice.

Long version

1. How hibernation works in Linux

   1.1 Freeze all user tasks.
   1.2 Take a snapshot of every physical page that is currently in RAM and of every kernel data structure that describes them (page tables, process state …).
   1.3 Compress that snapshot and write it to a specially marked area on disk – normally the swap space.
   1.4 Power goes off.

   On the next power-up a small piece of code in the kernel/ init-rd finds that image, reads it into RAM, uncompresses it and jumps back to the point where the snapshot was taken.
   In other words, after the jump the machine’s RAM contents and all the bookkeeping information are bit-for-bit identical to what they were a few seconds before hibernation.

   Important consequence:
   • If a page was resident in RAM when you hibernated, it is resident right after the resume – no I/O is necessary.
   • If a page had already been swapped out before you hibernated, it is still on the swap device, because it was not in RAM and therefore was not part of the image in step 1.2.

2. Why the system feels sluggish right after the resume

   The pages you are waiting for were already swapped out before the hibernate.
   You simply did not notice, because you were not using the machine at that instant.
   As soon as you start interacting with the desktop again those cold pages are touched and the kernel has to bring them back – exactly the same thing that would have happened if you had never hibernated but had left the machine idle for the same amount of time.

3. Why the kernel does not eagerly pull everything back in

   • The pages were swapped out precisely because RAM was full; there might still be no room for them.
   • Reading a large fraction of the swap area unconditionally can take tens of seconds or even minutes on spinning disks and would increase resume time for everyone, even when the pages will never be used.
   • Deciding which pages are worth prefaulting is a hard predictive problem and nobody has come up with a convincing, low-overhead algorithm that satisfies the kernel developers.

4. Existing / past work

   Around the 2.6-series kernels Con Kolivas maintained an out-of-tree “-ck” patch set that contained “Anticipatory Swap Prefetch” a.k.a. “Swap Prefetch”.
   That code tried to pull swapped pages back into RAM when the machine was completely idle. It was never merged and has not been maintained for current kernels for many years. If you really want the feature you would have to revive and forward-port that patch yourself.

5. What you can do in practice

   • Make sure the machine is not heavily swapped before you hibernate:
   – buy more RAM;
   – lower /proc/sys/vm/swappiness;
   – quit memory-hungry programs.

   • Put the swap device on a fast SSD; the fault-in latency then becomes much less noticeable.

   • If the machine can keep RAM powered, use suspend-to-RAM instead of hibernate; no pages are written to disk at all, so the problem disappears.

   • Accept the small delay – it is the price of having been short of RAM before hibernation.

So, to answer the precise question: there is no kernel configuration option that will “restore RAM + swap layout” in the way you imagine; the swap layout is already restored, and forcing all of it back into RAM is intentionally not done.