lmdb-map-size flag is not being preserved by cw_play_fork

[Gcec21]

_cw_play_fork() manually constructs a new argv[] for the child process, but does not forward the "--lmdb-map-size" option. As a result, the child cw_play never sees the flag.

For devices that cannot handle the default map size of 500GiB, this means that although they'll manage to, for example, mine a comet with "./urbit -c --lmdb-map-size 1073741824", once they exit the comet and try to rerun it with "./urbit mycomet --lmdb-map-size 1073741824", the process will fail with "lmdb: failed to open event log: Out of memory".

With a bunch of strategically added print statements for debugging, this is what the output looks like on a device with memory problems when you try to run a comet:

./urbit mycomet --lmdb-map-size 1073741824

urbit 3.5-35f7662d3d

boot: home is /home/gcec21/urbit/mycomet

[LMDB DEBUG] u3_lmdb_init: requested mapsize = 536870912000 bytes (512000.00 MiB)

[LMDB DEBUG] mdb_env_set_mapsize succeeded

[LMDB DEBUG] calling mdb_env_open(path='/home/gcec21/urbit/mycomet/.urb/log', flags=0x400000)

[LMDB DEBUG] mdb_env_open failed: code=12 (Out of memory)

lmdb: failed to open event log: Out of memory 

disk: failed to initialize lmdb

unable to open event log

play: failed: 1 signal: 0

In particular, note that although the lmdb-map-size flag was used, u3_lmdb_init still used the default value. Although _cw_play_fork receives the right map value, every function after it does not, leading to lmdb being handed the default map size. The output is identical when using mycomet/.run. On a device that supports the default memory size, everthing will run, but still ignoring the lmdb-map-size flag.