The `Broadcast`/`ResendWalletTransactions` interface is strange:

- it's the node saying to the wallet "Try to submit your unconfirmed transactions to the mempool again"
- it's called in one place by the node, in `SendMessages()` here: https://github.com/bitcoin/bitcoin/blob/c033c4b5cef89a654e4d9d5c5f9bd823871b068b/src/net_processing.cpp#L3515. `SendMessages()` is called on the message handling thread on a loop.
- the actual scheduling of when the wallet sends messages is handled in the `ResendWalletTransactions()` function itself, using the `nNextResend` and `nLastResend` wallet globals (which could as easily be static variables in `ResendWalletTransactions()`).

Therefore the only use of `Broadcast()` is to periodically prod the wallet. The wallet itself decides whether it's time to resend transactions. This could be done by scheduling regular calls to `ResendWalletTransactions()`, in the same way that we schedule regular wallet flushes here: https://github.com/bitcoin/bitcoin/blob/c033c4b5cef89a654e4d9d5c5f9bd823871b068b/src/wallet/init.cpp#L215.

A couple of minor implementation details:

- the call to `Broadcast()` in `SendMessages()` is protected by an if statement `if (!fReindex && !fImporting && !IsInitialBlockDownload()) {`. Those tests could be moved into `ResendWalletTransactions()` (through the `Chain` interface).
- The `Broadcast` notification passes in the `nTimeBestReceived` time of the best block. That could be fetched by `ResendWalletTransactions()` through the `Chain` interface.
bool fWantsCmpctWitness;
    /**
     * If we've announced NODE_WITNESS to this peer: whether the peer sends witnesses in cmpctblocks/blocktxns,
     * otherwise: whether this peer sends non-witnesses in cmpctblocks/blocktxns.
     */
    bool fSupportsDesiredCmpctVersion;
    /** State used to enforce CHAIN_SYNC_TIMEOUT
      * Only in effect for outbound, non-manual connections, with
      * m_protect == false
      * Algorithm: if a peer's best known block has less work than our tip,
      * set a timeout CHAIN_SYNC_TIMEOUT seconds in the future:
      *   - If at timeout their best known block now has more work than our tip
      *     when the timeout was set, then either reset the timeout or clear it
      *     (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.
      */
    struct ChainSyncTimeoutState {
        
        int64_t m_timeout;
        
        const CBlockIndex * m_work_header;
        
        bool m_sent_getheaders;
        
        bool m_protect;
    };