valgrind: leak in kvstxn path

[chu11]

While using the reproduces mentioned in #1940, also saw this memleak from valgrind.

I've seen it alteast once in both reproducer types:

src/cmd/flux start -s1 --wrap=libtool,e,valgrind,--leak-check=full,--trace-children=no,--suppressions=t/valgrind/valgrind.supp /bin/true

and

src/cmd/flux start -s2 --wrap=libtool,e,valgrind,--leak-check=full,--trace-children=no,--suppressions=t/valgrind/valgrind.supp flux exec -r 1 flux kvs get a

It is however infrequent, not happening everytime run.

==127578== HEAP SUMMARY:
==127578==     in use at exit: 35,854 bytes in 86 blocks
==127578==   total heap usage: 56,780 allocs, 56,694 frees, 52,126,132 bytes allocated
==127578== 
==127578== 112 (48 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 22
==127578==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==127578==    by 0x50B43EA: json_array (in /usr/lib64/libjansson.so.4.10.0)
==127578==    by 0xBBC3C77: kvstxn_create_empty (kvstxn.c:1292)
==127578==    by 0xBBC3C77: kvstxn_mgr_merge_ready_transactions (kvstxn.c:1353)
==127578==    by 0xBBBD15E: kvstxn_check_root_cb (kvs.c:1195)
==127578==    by 0xBBC433A: kvsroot_mgr_iter_roots (kvsroot.c:220)
==127578==    by 0xBBBBA7B: transaction_check_cb (kvs.c:1223)
==127578==    by 0x4E7F6B4: ev_invoke_pending (ev.c:3322)
==127578==    by 0x4E82826: ev_run (ev.c:3726)
==127578==    by 0x4E520A2: flux_reactor_run (reactor.c:126)
==127578==    by 0xBBBED3A: mod_main (kvs.c:3402)
==127578==    by 0x40A5A1: module_thread (module.c:144)
==127578==    by 0x57DDDD4: start_thread (pthread_create.c:308)
==127578== 
==127578== LEAK SUMMARY:
==127578==    definitely lost: 48 bytes in 1 blocks
==127578==    indirectly lost: 64 bytes in 1 blocks
==127578==      possibly lost: 0 bytes in 0 blocks
==127578==    still reachable: 35,230 bytes in 83 blocks
==127578==         suppressed: 512 bytes in 1 blocks
==127578== Reachable blocks (those to which a pointer was found) are not shown.
==127578== To see them, rerun with: --leak-check=full --show-leak-kinds=all

[chu11]

From PR #1859, key generation was changed and I overlooked at case where a key array could be created, then later overwritten without being destroyed.