### Expected behavior:

1. `importaddress` or `importpubkey` a watching-only address or pubkey with a label
2. Receive a transaction to that address; observe that the label has been applied to that transaction
3. `importprivkey` the private key for that address without specifying any change to the label
4. Have the previous label still applied to the transaction after the import.

### Observed behavior on 0.15 and current master:

Steps 1-3 the same.
4. Previous label is replaced with the default empty label ("")

Problem seems to have occurred on 0.15 and affects the latest master (see subsequent details).  I'd suspect all versions are affected, i.e. it's not a regression.

### Steps to reproduce

```bash
## For testing
ADDRESS=2N6Y2wdhd91mQnZ8qCeH6hT5aZZygXFnNjP
PRIVKEY=cQriWp98xU9ghRvDKbzkRcgcecQLezjYwtPUjLNN5kzT8GbdnxQt

## Starting a fresh regtest (i.e. ~/.bitcoin/regtest/ previously deleted)
$ bitcoind -daemon -regtest
Bitcoin server starting

## Import the address with a label and no rescan
$ bitcoin-cli -regtest importaddress $ADDRESS "Watch-only test" false

## Mine a generation tx to the address (regular spending works too)
$ bitcoin-cli -regtest generatetoaddress 1 $ADDRESS > /dev/null

## Bury the generation tx so it shows up in the wallet
$ bitcoin-cli -regtest generate 100 > /dev/null

## See that the address label was applied to the tx
$ bitcoin-cli -regtest listunspent | jq .[].label
"Watch-only test"

## Import the private key.  Note the 'label' parameter is not explicitly passed
$ bitcoin-cli -regtest importprivkey $PRIVKEY

## See that the address label has been set to empty :-(
$ bitcoin-cli -regtest listunspent | jq .[].label
```

Same thing happens if `importpubkey` is substituted for `importaddress`.  I haven't tested `importmulti` for either address/pubkey or privkey import, nor have I tested using named parameters.

### Use case

I was watching-only addresses from my cold wallet, then moved my coins to new addresses and (after some confirmations) imported the old private keys so that I could sell fork coins.  I didn't realize until now when I was trying to do some bookkeeping that all my old cold wallet labels were reset (happily, I have backups, so nothing is lost but time).

### Possibly related issues

- #12698 looks related but the poster there says that it works on mainnet.  I discovered my problem from actual use on mainnet and reproduced on regtest.
if (!request.params[2].isNull())
        fRescan = request.params[2].get_bool();
    if (fRescan && fPruneMode)
        throw JSONRPCError(RPC_WALLET_ERROR, "Rescan is disabled in pruned mode");
    WalletRescanReserver reserver(pwallet);
    if (fRescan && !reserver.reserve()) {
        throw JSONRPCError(RPC_WALLET_ERROR, "Wallet is currently rescanning. Abort existing rescan or wait.");
    }
    if (!IsHex(request.params[0].get_str()))
        throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Pubkey must be a hex string");
    std::vector<unsigned char> data(ParseHex(request.params[0].get_str()));
    CPubKey pubKey(data.begin(), data.end());
    if (!pubKey.IsFullyValid())
        throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Pubkey is not a valid public key");
    {
        LOCK2(cs_main, pwallet->cs_wallet);
        for (const auto& dest : GetAllDestinationsForKey(pubKey)) {
            ImportAddress(pwallet, dest, strLabel);
        }
        ImportScript(pwallet, GetScriptForRawPubKey(pubKey), strLabel, false);
        pwallet->LearnAllRelatedScripts(pubKey);
    }
    if (fRescan)
    {
        RescanWallet(*pwallet, reserver);
        pwallet->ReacceptWalletTransactions();
    }
    return NullUniValue;
}
UniValue importwallet(const JSONRPCRequest& request)