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.
*/
    std::map<uint256, std::pair<NodeId, bool>> mapBlockSource GUARDED_BY(cs_main);
    /**
     * Filter for transactions that were recently rejected by
     * AcceptToMemoryPool. These are not rerequested until the chain tip
     * changes, at which point the entire filter is reset.
     *
     * Without this filter we'd be re-requesting txs from each of our peers,
     * increasing bandwidth consumption considerably. For instance, with 100
     * peers, half of which relay a tx we don't accept, that might be a 50x
     * bandwidth increase. A flooding attacker attempting to roll-over the
     * filter using minimum-sized, 60byte, transactions might manage to send
     * 1000/sec if we have fast peers, so we pick 120,000 to give our peers a
     * two minute window to send invs to us.
     *
     * Decreasing the false positive rate is fairly cheap, so we pick one in a
     * million to make it highly unlikely for users to have issues with this
     * filter.
     *
     * Memory used: 1.3 MB
     */
    std::unique_ptr<CRollingBloomFilter> recentRejects GUARDED_BY(cs_main);
    uint256 hashRecentRejectsChainTip GUARDED_BY(cs_main);
    
    struct QueuedBlock {
        uint256 hash;
        const CBlockIndex* pindex;                               
        bool fValidatedHeaders;                                  
        std::unique_ptr<PartiallyDownloadedBlock> partialBlock;  
    };