There are some potential feefilter cleanups mentioned and motivated in comment https://github.com/bitcoin/bitcoin/pull/21509#issuecomment-805808485 . If you address the locking one, please be careful and make sure that `round()` is only called under a lock. See https://github.com/bitcoin/bitcoin/pull/21509#issuecomment-807992199

#### Useful skills:

* Bitcoin protocol messages
* Bitcoin Core P2P design
* Running our unit and functional tests

#### Want to work on this issue?

For guidance on contributing, please read [CONTRIBUTING.md](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md) before opening your pull request.

*     (after comparing against our current tip's work)
      *   - If at timeout their best known block still has less work than our
      *     tip did when the timeout was set, then send a getheaders message,
      *     and set a shorter timeout, HEADERS_RESPONSE_TIME seconds in future.
      *     If their best known block is still behind when that new timeout is
      *     reached, disconnect.
      *
      * EXTRA_PEER_CHECK_INTERVAL: after each interval, if we have too many outbound peers,
      * drop the outbound one that least recently announced us a new block.
      */
    struct ChainSyncTimeoutState {
        
        int64_t m_timeout{0};
        
        const CBlockIndex* m_work_header{nullptr};
        
        bool m_sent_getheaders{false};
        
        bool m_protect{false};
    };
    ChainSyncTimeoutState m_chain_sync;
    
    int64_t m_last_block_announcement{0};
    
    const bool m_is_inbound;
    
    CRollingBloomFilter m_recently_announced_invs = CRollingBloomFilter{INVENTORY_MAX_RECENT_RELAY, 0.000001};
    
    bool m_wtxid_relay{false};
    CNodeState(bool is_inbound) : m_is_inbound(is_inbound) {}