<SYSTEM_TASK:>
Solve the following problem using Python, implementing the functions described below, one line at a time
<END_TASK>
<USER_TASK:>
Description:
 def send_message_tracked(self, msg):
 """ Send a message to the MUC with tracking. :param msg: The message to send. :type msg: :class:`aioxmpp.Message` .. warning:: Please read :ref:`api-tracking-memory`. This is especially relevant for MUCs because tracking is not guaranteed to work due to how :xep:`45` is written. It will work in many cases, probably in all cases you test during development, but it may fail to work for some individual messages and it may fail to work consistently for some services. See the implementation details below for reasons. The message is tracked and is considered :attr:`~.MessageState.DELIVERED_TO_RECIPIENT` when it is reflected back to us by the MUC service. The reflected message is then available in the :attr:`~.MessageTracker.response` attribute. .. note:: Two things: 1. The MUC service may change the contents of the message. An example of this is the Prosody developer MUC which replaces messages with more than a few lines with a pastebin link. 2. Reflected messages which are caught by tracking are not emitted through :meth:`on_message`. There is no need to set the address attributes or the type of the message correctly; those will be overridden by this method to conform to the requirements of a message to the MUC. Other attributes are left untouched (except that :meth:`~.StanzaBase.autoset_id` is called) and can be used as desired for the message. .. warning:: Using :meth:`send_message_tracked` before :meth:`on_join` has emitted will cause the `member` object in the resulting :meth:`on_message` event to be :data:`None` (the message will be delivered just fine). Using :meth:`send_message_tracked` before history replay is over will cause the :meth:`on_message` event to be emitted during history replay, even though everyone else in the MUC will -- of course -- only see the message after the history. :meth:`send_message` is not affected by these quirks. .. seealso:: :meth:`.AbstractConversation.send_message_tracked` for the full interface specification. **Implementation details:** Currently, we try to detect reflected messages using two different criteria. First, if we see a message with the same message ID (note that message IDs contain 120 bits of entropy) as the message we sent, we consider it as the reflection. As some MUC services re-write the message ID in the reflection, as a fallback, we also consider messages which originate from the correct sender and have the correct body a reflection. Obviously, this fails consistently in MUCs which re-write the body and re-write the ID and randomly if the MUC always re-writes the ID but only sometimes the body. """

        msg.type_ = aioxmpp.MessageType.GROUPCHAT
        msg.to = self._mucjid
        # see https://mail.jabber.org/pipermail/standards/2017-January/032048.html  # NOQA
        # for a full discussion on the rationale for this.
        # TL;DR: we want to help entities to discover that a message is related
        # to a MUC.
        msg.xep0045_muc_user = muc_xso.UserExt()
        msg.autoset_id()
        tracking_svc = self.service.dependencies[
            aioxmpp.tracking.BasicTrackingService
        ]
        tracker = aioxmpp.tracking.MessageTracker()
        id_key = msg.id_
        body_key = _extract_one_pair(msg.body)
        self._tracking_by_id[id_key] = tracker
        self._tracking_metadata[tracker] = (
            id_key,
            body_key,
        )
        self._tracking_by_body.setdefault(
            body_key,
            []
        ).append(tracker)
        tracker.on_closed.connect(functools.partial(
            self._tracker_closed,
            tracker,
        ))
        token = tracking_svc.send_tracked(msg, tracker)
        self.on_message(
            msg,
            self._this_occupant,
            aioxmpp.im.dispatcher.MessageSource.STREAM,
            tracker=tracker,
        )
        return token, tracker