possible bug dumping log at startup

[paul mineiro]

i found this by inspecting the code. it would only be tickled by
dumping the log at startup, and i don't know how to get that to happen
exactly (try to crash the node at an inopportune time?)

anyway, here's what i found:

* if the log is dumped during startup, mnesia_dumper:disc_insert/8
can be called from mnesia_dumper:insert/8, even if Storage ==
{ external_copies, Mod }
* in mnesia_dumper:disc_insert/8, mnesia_dumper:dets_insert/4 can be
called if mnesia_dumper:open_files/4 returns true and Storage is
anything but disc_copies (and Tab is not schema)
* mnesia_dumper:open_files/4 always returns true for external_copies
tables
* mnesia_dumper:dets_insert/4 contains dets specific hacks.

so two issues:

1. mnesia_dumper:dets_insert/4 is going to call dets functions on
external_copies tables; these will fail.
2. the fixups that dets_insert/4 is doing (like, making sure
update_counter is not applied twice) might need to be done for
external_copies tables as well.

i don't fully understand how the LATEST.LOG stuff works with
disc_only_copies (and by extension, external_copies). things make
sense in the ram_copies world (where the dumper is not used) and the
disc_copies world (where there are two representations of the data,
one in ram and one in disk, so doing each update seems reasonable).
however in the disc_only_copies case the on-disk representation is
updated when the transaction succeeds, and then updated again when the
log is dumped (?) and it looks like they are playing some games in
mnesia_dumper.erl to make it work.