During some lock debugging on a dual-core Linux system I noticed that threads are blocked acquiring `cs_vNodes` and `cs_main` for long periods when the system is under moderate load from unrelated processes -- the unlucky lock acquirer is waiting for single-digit seconds once every 10 minutes or so (not coinciding with new blocks) up to around a 30 second wait every few hours. It looks like `ThreadMessageHandler` is taking locks and then due to being set to `THREAD_PRIORITY_BELOW_NORMAL`, it's being descheduled (even in trivial lock-holding regions like `GetHeight`) and holding up for arbitrarily long periods other threads that use these core locks.

So I'm wondering, what are the benefits of running the message handler at low priority?

if (!ssSend.empty()) {
            CDataStream::size_type pos = GetRand(ssSend.size());
            ssSend[pos] ^= (unsigned char)(GetRand(256));
        }
        break;
    case 1:
        
        if (!ssSend.empty()) {
            CDataStream::size_type pos = GetRand(ssSend.size());
            ssSend.erase(ssSend.begin()+pos);
        }
        break;
    case 2:
        
        {
            CDataStream::size_type pos = GetRand(ssSend.size());
            char ch = (char)GetRand(256);
            ssSend.insert(ssSend.begin()+pos, ch);
        }
        break;
    }
    
    
    Fuzz(2);
}
CAddrDB::CAddrDB()
{
    pathAddr = GetDataDir() / "peers.dat";
}
bool CAddrDB::Write(const CAddrMan& addr)