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.
*   For transactions that we still need but we have already recently
     *   requested from some other peer, we'll reinsert (process_time, txid)
     *   back into the peer's m_tx_process_time at the point in the future at
     *   which the most recent GETDATA request would time out (ie
     *   GETDATA_TX_INTERVAL + the request time stored in g_already_asked_for).
     *   We add an additional delay for inbound peers, again to prefer
     *   attempting download from outbound peers first.
     *   We also add an extra small random delay up to 2 seconds
     *   to avoid biasing some peers over others. (e.g., due to fixed ordering
     *   of peer processing in ThreadMessageHandler).
     *
     *   When we receive a transaction from a peer, we remove the txid from the
     *   peer's m_tx_in_flight set and from their recently announced set
     *   (m_tx_announced).  We also clear g_already_asked_for for that entry, so
     *   that if somehow the transaction is not accepted but also not added to
     *   the reject filter, then we will eventually redownload from other
     *   peers.
     */
    struct TxDownloadState {
        /* Track when to attempt download of announced transactions (process
         * time in micros -> txid)
         */
        std::multimap<int64_t, uint256> m_tx_process_time;
        
        std::set<uint256> m_tx_announced;
        
        std::set<uint256> m_tx_in_flight;
    };
    TxDownloadState m_tx_download;
    CNodeState(CAddress addrIn, std::string addrNameIn) : address(addrIn), name(addrNameIn) {