When `bitcoin-cli` is run, **it, not bitcoind** creates an empty `~/.bitcoin/wallets` direcctory with `~` bring home of currently running user. This is weird and leads to user confusion because it happens even in cases when `bitcoin-cli` connects to a `bitcoind` running under a different user or probably on other machine.

**Expected behavior**

`bitcoin-cli` never modifies filesystem, especially not things that the daemon should take care of.

**Actual behavior**

`bitcoin-cli creates empty directory`

**To reproduce**

0. make sure `~/.bitcoin` does **not** exist under user A
1. install `bitcoind` and run it under a user B
2. run `bitcoin-cli getblockchaininfo` under user A
3. `ls ~/.bitcoin` under user A

For quick setup, you can try to use [my project](https://deb.ln-ask.me) in a Debian VM or using provided Docker file. Just `apt install bitcoin-regtest bitcoin-cli`, it's already pre-configured to run under a different user, so then just running `sudo bitcoin-cli getblockchaininfo && sudo ls /root/.bitcoin` should reproduce the issue.

**System information**

0.20 official release downloaded from `https://bitcoin.org/bin/bitcoin-core-...`, verified GPG signature from Wladimir.

OS: Linux Debian Buster
CPU: Intel x86_64
Disk: NVMe SSD
FS: ext4

I don't think configuration is relevant since `bitcoin-cli` is **not** informed where to find it (via parameters or otherwise) and thus it can **not** access it. I also added `-rpcport` and `-rpccookiefile` parameters explicitly but I don't think it's relevant.

Loosely related to #16220, but not a duplicate.
#else
#include <codecvt>
#include <io.h> 
#include <shellapi.h>
#include <shlobj.h>
#endif
#ifdef HAVE_MALLOPT_ARENA_MAX
#include <malloc.h>
#endif
#include <univalue.h>
#include <fstream>
#include <map>
#include <memory>
#include <optional>
#include <string>
#include <system_error>
#include <thread>
#include <typeinfo>
const int64_t nStartupTime = GetTime();
const char * const BITCOIN_CONF_FILENAME = "bitcoin.conf";
const char * const BITCOIN_SETTINGS_FILENAME = "settings.json";
ArgsManager gArgs;
static GlobalMutex cs_dir_locks;
/** A map that contains all the currently held directory locks. After
 * successful locking, these will be held here until the global destructor
 * cleans them up and thus automatically unlocks them, or ReleaseDirectoryLocks
 * is called.
 */
static std::map<std::string, std::unique_ptr<fsbridge::FileLock>> dir_locks GUARDED_BY(cs_dir_locks);
bool LockDirectory(const fs::path& directory, const fs::path& lockfile_name, bool probe_only)