mass: return memory report to arvo

[tinnus-napbus]

Dill can give Vere a [%quac ~] gift and vere returns a memory report in a [%quac p=(list quac)] where a quac is a [name=@t size=@ud quacs=(list quac)] nested memory report structure. Vere itself does not print the memory report in this case, but it still does when requested with the old |mass/%heft and grab from the command-line. Arvo will implement its own memory report printer for quacs.

Unlike the previous version that used a fake driver to inject the report, this does it properly through Dill's driver, using a %quiz plea/writ to query the serf for this info.

[matthew-levan]

Is this an unintentional addition from a merge commit?

[tinnus-napbus]

@pkova do you know where this came from? Should I remove this or is it from that thingy you merged in?

[tinnus-napbus]

I think maybe I accidentally squashed in something you merged. If it just manually remove the extra changes will it screw things up if you subsequently merge that thing into develop or wherever?

[pkova]

This is fine to remove from this PR, it corresponds to this stuff that's already on develop:

vere/pkg/vere/main.c

Lines 3316 to 3325 in 58aa31c

	// validate whether we can execute disk migration
	if ( u3_Host.ops_u.nuu == c3n ) {
	c3_i sat_i = _cw_play_fork(0, 0, c3n, c3n, c3n);
	if ( sat_i ) {
	fprintf(stderr, "play: replay failed\r\n");
	exit(sat_i);
	}
	signal(SIGTSTP, _stop_exit);
	// XX unmap loom, else parts of the snapshot could be left in memory
	}

[matthew-levan]

Perhaps you could condense _serf_quac and _serf_quacs to a single function that returns just a quac noun or a (list quac) depending on the len_w parameter?

[tinnus-napbus]

I'm wary of a function that returns two different hoon types depending on its arg. Do you think that's ok?