Support forced fetch

[ivankolesnikov]

Recently (a few days ago) Facebook changed the API again and now a complex message (e.g. a message with a button) is not returned directly anymore, but has to be loaded via /api/graphqlbatch.

Without this change, the library simply skips the message.

Traffact example.

Send the following message using official messenger API:

{
    "attachment": {
        "type": "template",
        "payload": {
            "template_type": "button",
            "text": "Test",
            "buttons": [
                {
                    "title": "A button",
                    "type": "postback",
                    "payload": "12345"
                }
            ]
        }
    }
}

Facebook Web Messenger traffic:

1. Delta package with class set to ForcedFetch, no message itself:

{
    "t":"msg",
    "seq":37,
    "u":100010714633094,
    "ms":[
        {
            "ofd_ts":1522169287367,
            "delta":{
                "messageId":"mid.$cAAQloL0-eD5omaFaqFiaFwRnxhI1",
                "threadKey":{
                    "otherUserFbId":"1265903796808632"
                },
                "class":"ForcedFetch"
            },
            "type":"delta",
            "iseq":12952,
            "queue":100010714633094
        }
    ]
}

2. A separate GraphQL call to load the message: URL: https://www.messenger.com/api/graphqlbatch Query:

{
    "o0": ...,
    "o1":{
        "doc_id":"1801329719924418",
        "query_params":{
            "thread_and_message_id":{
                "thread_id":"1265903796808632",
                "message_id":"mid.$cAAQloL0-eD5omaFaqFiaFwRnxhI1"
            }
        }
    }
}

3. Send ack: https://www.messenger.com/ajax/mercury/delivery_receipts.php

The change is not small... I tried to split it on two commits for easy review:

1. Extract graphqlbatch and the message transformer into graphQLUtils.js - only refactoring here
2. Handle messages with ForcedFetch class - implementation

[Toohpick]

This is starting to affect more common types of messages including some regular shares, not just messages with buttons. @Schmavery, what do you think about this?

[Schmavery]

Sorry I missed this everyone.

I'm not against merging something like this if it's still useful.

In the future, it's easier to review a large PR like this the moving of existing code to another file is one commit on its own, without any modifications (even if it doesn't run properly). Then the other commit(s) afterward can modify it. Then I don't need to remember which parts are copied and which parts are modified. Thanks for making an effort to split the PR into two commits on this one, but it seems like there was still a large code move + changes in the first commit.

[ivankolesnikov]

@Schmavery, I agree, it is hard to review it as is. I split the commits. Now it should be easier to review.

I don't use this project and facebook for around a year and not even sure my change still makes sense and works as expected. It would be nice if someone else finishes it if it is useful.