plugin: let plugins decide if they want echo removal during AT probing

This is the port to git master of the following patch:

commit 21e66dfa1774ac2ee037ac8b6e8bb4d71a6f7931
Author: Dan Williams <dcbw@redhat.com>
Date:   Thu Aug 23 21:13:35 2012 -0500

    core: add function to open probe ports without removing echo

    Some devices (Sierra GSM ones) return stuff we need but don't
    bother to prefix it with <CR><LF>, so we need to optionally turn
    off the echo removal at probe time.
sierra: fix detection of APP1 port

This is the port to git master of the following commit:

commit e0242b4db7fb1556e79f6829d22edf411f9f6ba4
Author: Dan Williams <dcbw@redhat.com>
Date:   Thu Aug 23 21:14:38 2012 -0500

    sierra: fix detection of APP1 port

    The APP1 port (which has a limited AT parser) doesn't prefix
    its replies with <CR><LF> like nice modems do, and that means
    it runs afoul of the echo removal bits of the AT serial port
    code.  We need to parse the whole string even though it's not
    prefixed properly to find the APP1 string in the response.
test: add utility to force a modem disconnect
icera: retry configuring PDP context if it fails.

This is the port to git master of the following commit:

commit fb3187847b9c62d5205962c3c707ac1f44eaddcc
Author: Eric Shienbrood <ers@chromium.org>
Date:   Thu Aug 11 16:58:34 2011 -0400

    icera: retry configuring PDP context if it fails.

    If a connect operation is attempted immediately after a disconnect,
    it sometimes fails with CME error 583 - "a profile (CID) is currently
    active". Apparently, even though the preceding operation (%IPDPACT)
    to deactivate the PDP context returned an OK response, the context
    is not really completely available until a fraction of a second
    later. This causes the %IPDPCFG operation that is part of the
    subsequent connect attempt to fail with error 583. This change
    retries the %IPDPCFG after a one second delay.

    BUG=chrome-os-partner:4936
    TEST=This can be tested from the UI, but I found it easier to produce
    the timing needed to trigger the bug by running mm-disconnect and
    mm-connect from a shell.

    Start out with the modem in the connected state. In the shell, run

      sudo /usr/local/lib/flimflam/test/mm-disconnect; sudo /usr/local/lib/flimflam/test/mm-connect --number='*99#' --apn=wap.cingular

    modem-manager should emit the log line "Invalid error code: 583".
    Prior to this change, the connect operation would fail. Now it should
    succeed.

    Change-Id: I6ae0e6a9f5405b54b0b465fe91d9542529f365c2
    Reviewed-on: http://gerrit.chromium.org/gerrit/5781
    Tested-by: Eric Shienbrood <ers@chromium.org>
    Reviewed-by: Nathan J. Williams <njw@chromium.org>
novatel: fix checking ERI for roaming/home decision

This is a port to git master of the following commit:

commit c21e29c50b5661308fb3b223c05f6942c06dc15d
Author: Dan Williams <dcbw@redhat.com>
Date:   Fri Aug 24 13:31:04 2012 -0500

    novatel: fix checking ERI for roaming/home decision

    More fallout from b22b2d99db57e4cec8e6c3074dd20acd6845cb62
    which changed the return type of the qcdm_result_get_*() functions.
sim: better handling of IMSI response

This is a port to git master of the following commit:

commit 0b051f9c7033143c56f59267794d1cadf4bd3416
Author: Dan Williams <dcbw@redhat.com>
Date:   Mon Aug 27 10:24:50 2012 -0500

    gsm: better handling of IMSI response

    Moto EZX devices prefix the response with "+CIMI:" while most
    devices do not.
mbm: add Ericsson H5321gw (often found in Thinkpad X230)
api,introspection: new `Data' property in the SMS interface

We need to expose the raw data for the case where we get SMS messages with
binary content (e.g. settings SMS).
sms: fix handling of 'data' property for multipart messages

This is the port to git master of the following commit:

commit 1c29ce5999d11dee2898e7bf41c00995a00c71d0
Author: Dan Williams <dcbw@redhat.com>
Date:   Mon Aug 27 17:36:49 2012 -0500

    sms: fix handling of 'data' property for multipart messages

    Text was getting concatenated when reconstructing the full message,
    but the data wasn't.  That meant that non-text multipart messages,
    like the binary APN/MMS settings messages that operators often send,
    were broken.
broadband-modem: if the generic CNMI request fails, try a Qualcomm-compatible one

This is the port to git master of the following commit:

commit 1d9164ec90788d1be134482ff88c501e3c5d623c
Author: Dan Williams <dcbw@redhat.com>
Date:   Mon Aug 27 18:20:33 2012 -0500

    gsm: if the generic CNMI request fails, try a Qualcomm-compatible one

    Many devices based on Qualcomm chipsets don't support a <ds> value
    of '1', despite saying they do in the AT+CNMI=? response.  But they
    do accept '2'.  Since we're not doing much with delivery status
    reports yet, if we get a CME 303 (not supported) error when setting
    the message indication parameters via CNMI, fall back to the
    Qualcomm-compatible CNMI parameters.

    If we don't do this, we don't get SMS indications on these devices,
    because the original CNMI failed.

    Tested on Huawei E1550, Huawei E160G, ZTE MF622, and Novatel XU870.
sierra: use an additional AT+WS46=? to detect LTE capabilities

Some Sierra modems (e.g. MC7710) will report LTE-specific supported modes in the
AT+WS46=? reply, but not +CLTE capability in the AT+GCAP reply:

AT+GCAP
 +GCAP: +CGSM
 OK

AT+WS46=?
 +WS46: (12,22,25,28,29)
 OK
zte: handle Icera-based devics that use DHCP

This is the port to git master of the following commit:

commit d2654a287c309346cc46b535dd974b0a5fc06fd4
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Aug 28 12:15:30 2012 -0500

    zte: handle Icera-based devics that use DHCP

    Since we can't autodetect that the devices use DHCP, we'll need to
    tag them with udev rules for the time being.
modem-helpers: new helper to convert from netmask string to CIDR
icera: handle additional IPv4 configuration options

This is the port to git master of the following commit:

commit c8153b1ecdec1995258b114c90b575af1e721d3d
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Aug 28 12:16:26 2012 -0500

    icera: handle additional IPv4 configuration options

    Newer devices like the ZTE/Vodafone K3805-z have an enhanced
    %IPDPADDR command that includes a netmask and gateway, and
    these are necessary to configure the device since it uses /24
    instead of a /32.  Since the device is nice enough to tell
    us that, we should probably use that information.

    Unfortunately the MM API doens't expose the netmask and gateway
    yet, so we'll have to add a GetIP4ConfigEx() method or something
    like that, but this commit sets us up to do that.
sierra: use DHCP for the USB 305 (AT&T Lightning)

This is the port to git master of the following commit:

commit 44f70121f75d59dbf31a4a9a1a4e87293e509e7a
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Aug 28 20:18:40 2012 -0500

    sierra: use DHCP for the USB 305 (AT&T Lightning)

    For some reason, my AT&T Lightning just doesn't work with static
    IP (AT%IPDPADDR) any more.  No traffic passes even though everything
    is set up the way it was before.  No idea what happened.  Using
    latest firmware 2.0.0.11.

    But what's interesting is on Windows the generic Sierra Watcher
    app uses DHCP.  But on Linux, when using AT%IPDPACT, DHCP doesn't
    work.  That's odd.  But it turns out the modem supports the
    "standard" Sierra proprietary AT!SCACT commands, and that
    *does* make DHCP work.  Crazy no?  So since the Windows app
    uses DHCP, it's likely that the non-DHCP case (AT%IPDPACT/AT%IPDPADDR)
    either isn't well tested or isn't well supported.  With that
    in mind, let's just use DHCP for this device in Linux too.
port-probe: speed up QCDM probing a bit

This is the port to git master of the following commit:

commit 01201860de5565a78823913423c6b2a762e3731f
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Aug 28 21:12:14 2012 -0500

    core: speed up QCDM probing a bit

    The point of sending two "version info" commands was to ensure that
    the terminating 0x7E of the first one was processed as a QCDM frame
    boundary and that any random data in the buffer (like AT commands
    from probing) got cleared out.  The second command would always
    get processed as a valid QCDM command if the device supported QCDM,
    since there was no garbage before it.

    Instead of that dance, just prepend the version info message with
    an extra 0x7E to ensure a clean QCDM frame which the device hopefully
    responds to immediately.  Second, actually process that response
    instead of throwing it away.  Should save about 3 seconds when
    probing QCDM ports.
sierra: skip echo removal in the secondary port

This is the port to git master of the following commit:

commit d1be19d231a395339b1f452d1a30b73ea77ad528
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Aug 28 21:58:43 2012 -0500

    sierra: fix CSQ handling on APP1 port

    The APP1 port doesn't always prefix its replies with <CR><LF> which
    runs afoul of the built-in echo removal.  Since Sierra modems are on
    the whole well-behaved WRT echo removal, just disable it on the
    secondary ports.  Only changes behavior for PPP-based devices since
    they are the only ones that use the APP1 ports.
huawei: additional unsolicited messages to ignore
sierra: allow users to help debug APP1 PPP capability

Most Sierra PPP-based devices are supposed to allow PPP on the
APP1 port, which has a dumb AT parser, leaving the main port
(with the intelligent AT parser) free for status and signal strength.
But out of all the devices I've tested it with (8775, 8781, AC881,
and C885), only the C885 actually works.  The rest (including three
different firmware versions for the 8775) either crash or disconnect
shortly after PPP starts.

To help figure out which devices actually support this, when
running MM in debug mode, users can set the MM_SIERRA_APP1_PPP_OK
environment variable and assume the APP1 port allows PPP.  This
is only for debugging purposes.