When the mempool fills the verbose `getrawmempool` RPC call gets really slow.  It can take minutes for >100k transactions in the mempool.

The culprit is the univalue library.  Objects are implemented as a big list, but the library checks for duplicate keys.  So inserting n key-value pairs into an object takes O(n^2).

Possible fixes:

- Improve univalue library by using linked hash maps.
- change the RPC output format of getrawmempool to use a list of objects, instead of an object of objects.  But this breaks existing code.
- hack the library to be able to skip the duplicate check.

" \"total_amount\" : x.xxx,          (numeric) The total amount of all found unspent outputs in " + CURRENCY_UNIT + "\n"
            "]\n"
                },
                RPCExamples{""},
            }.ToString()
        );
    RPCTypeCheck(request.params, {UniValue::VSTR, UniValue::VARR});
    UniValue result(UniValue::VOBJ);
    if (request.params[0].get_str() == "status") {
        CoinsViewScanReserver reserver;
        if (reserver.reserve()) {
            
            return NullUniValue;
        }
        result.pushKV("progress", g_scan_progress);
        return result;
    } else if (request.params[0].get_str() == "abort") {
        CoinsViewScanReserver reserver;
        if (reserver.reserve()) {
            
            return false;
        }
        
        g_should_abort_scan = true;
        return true;
    } else if (request.params[0].get_str() == "start") {
        CoinsViewScanReserver reserver;
        if (!reserver.reserve()) {
            throw JSONRPCError(RPC_INVALID_PARAMETER, "Scan already in progress, use action \"abort\" or \"status\"");
        }