class RemoteZygote

Two zygotes can be spliced together by consuming the other one and moving

all its modules into *this, which is the same as if all the Insert()

options done on other had been done on *this instead.

std::move(zygote1) + std::move(zygote2) + ...

A default-constructed zygote is empty and does not take much space.

This does the same as `*this = {};`.

This consumes a Linker, distilling its dynamic linking session into the

zygote and a Domain object. The Linker should already have been used to

Load and Commit in the initial process whose VMARs were used to do the

address layout for the zygote. (The state of that process no longer

matters. No handles to its VMARs are held after Commit.) Processes

loaded by the new zygote will start out identical to that process and

share both its VMOs for read-only segments (including RELRO) and its

parent VMOs (and their unmodified pages) for relocated data.

This can be used multiple times to add additional dynamic linking domains

from separate dynamic linking sessions. That modifies the zygote so that

a process loaded from it loads both sessions' modules, including each

session's own stub dynamic linker providing its own passive ABI view.

Inserting multiple sessions into one zygote and then calling Load() is no

different from creating separate zygote objects for each session and

calling Load() on all of them.

The only error return is for a failure to duplicate a VMO handle. If

RemoteZygoteVmo::kDecodedPtr is used, then no error is possible. The

returned Domain object gives the entry point and stack size request for

the main module, which is the first root module in the dynamic linker

session, such as the main executable; and the passive ABI root addresses.

If this is a RemoteZygoteVmo::kVmo object, then another zygote object of

the RemoteZygoteVmo::kDecodedPtr flavor can also be spliced in. This

always consumes that object and will drop all its ld::RemoteDecodedModule

references. It can fail when duplicating the VMO handles owned by them.

Clone the prototype process into another new process. The VMAR must be

some process's root VMAR or a sub-VMAR covering the same address space

bounds as the prototype process VMAR passed to Linker::Allocate.

This is non-destructive to the RemoteZygote object, and no references to

this object are made so its lifetime has no effect on the target process.

There is no separate Commit phase. When this returns false after an error

in loading, any sub-VMARs already created will have been destroyed.

On success, a closed VMAR for each module has all its mappings in place;

they cannot be modified. While zx_vmar_destroy cannot be used since there

is no handle to them, it's always possible to destroy a whole VMAR as an

atomic unit with a zx_vmar_unmap call on a handle to a containing VMAR.

It's not advised to use a Diagnostics object that says to keep going for

errors in this call. If the Diagnostics object does say to keep going,

this call will fail and return early for some errors but for others it

will keep going as directed and if it returned true after errors it may

have left partial mappings in the process.