Some operators provide IP address of the MMS proxy
prepending zeros to each number shorter then 3 digits,
e.g. "192.168.094.023" instead of "192.168.94.23".
That may look nicer but it's actually wrong because
the numbers starting with zeros are interpreted as
octal numbers. In the example above 023 actually means
16 and 094 is not a valid number at all.

In addition to publishing these broken settings on their
web sites, some of the operators send them over the air,
in which case we can't even blame the user for entering
an invalid IP address. We better be prepared to deal with
those.

Since nobody in the world seems to be actually using the
octal notation to write an IP address, let's remove the
leading zeros if we find them in the host part of the MMS
proxy URL.

Pass MMS location URL to the handler

See merge request !15

It allows the handler to ignore duplicate push notifications.

We are not using those, it was just adding unnecessary overhead

We never reuse the connection and operators usually reply with
"Connection: close" anyway. Also, some carriers actually require
Connection to be "close"

Always allow X-Mms-Transaction-ID header

See merge request !14

DNA Finland recently started to include X-Mms-Transaction-ID in
M-Delivery.ind even though it's not supposed to be there at all.
We should allow (and ignore) it.

Fix parsing of the absolute date header

It went unnoticed because usually the expiry time is relative.

See merge request !13

Make default settings configurable

Defaults for things like user agent and UAProfile should be modifiable
with /etc/mms-engine.conf file installed by the hardware adaptation
package. Config file name can also be specified from the command line.

See merge request !12

Defaults for things like user agent and UAProfile should be modifiable
using a file installed by the hardware adaptation package.

Logging functionality that used to be part of mms-engine has been
migrated to libglibutil

Fixed compilation against libsoup 2.48 and newer

This gets rid of a few compile time and runtime warnings.

See merge request !11

See merge request !10

According to valgrind:

16 bytes in 2 blocks are definitely lost in loss record 1,408 of 3,437
   at 0x4841B84: calloc (vg_replace_malloc.c:623)
   by 0x51620C3: g_malloc0 (gmem.c:134)
   by 0x1F9CB: mms_transfer_dbus_handle_enable_updates (mms_transfer_dbus.c:246)

if the corresponding conversation is open in Messages UI when MMS is being
sent or received.

Transfer progress API

Intended for the Messages app, so that it can show MMS
send/receive progress.

D-Bus interface for the list of transfers goes like this:

<interface name="org.nemomobile.MmsEngine.TransferList">
    <method name="Get">
        <arg name="list" type="ao" direction="out"/>
    </method>
    <signal name="TransferStarted">
        <arg name="path" type="o"/>
    </signal>
    <signal name="TransferFinished">
        <arg name="path" type="o"/>
    </signal>
</interface>

D-Bus interface for individual transfers (identified by path):

<interface name="org.nemomobile.MmsEngine.Transfer">
    <method name="GetAll">
        <arg name="version" type="u" direction="out"/>
        <arg name="bytes_sent" type="u" direction="out"/>
        <arg name="bytes_to_send" type="u" direction="out"/>
        <arg name="bytes_received" type="u" direction="out"/>
        <arg name="bytes_to_receive" type="u" direction="out"/>
    </method>
    <method name="EnableUpdates">
        <!-- 1 - send, 2 - receive, 3 - both -->
        <arg name="flags" type="u" direction="in"/>
        <arg name="cookie" type="u" direction="out"/>
    </method>
    <method name="DisableUpdates">
        <arg name="cookie" type="u" direction="in"/>
    </method>
    <method name="GetInterfaceVersion">
        <arg name="version" type="u" direction="out"/>
    </method>
    <method name="GetSendProgress">
        <arg name="bytes_sent" type="u" direction="out"/>
        <arg name="bytes_to_send" type="u" direction="out"/>
    </method>
    <method name="GetReceiveProgress">
        <arg name="bytes_received" type="u" direction="out"/>
        <arg name="bytes_to_receive" type="u" direction="out"/>
    </method>
    <signal name="SendProgressChanged">
        <arg name="bytes_sent" type="u"/>
        <arg name="bytes_to_send" type="u"/>
    </signal>
    <signal name="ReceiveProgressChanged">
        <arg name="bytes_received" type="u"/>
        <arg name="bytes_to_receive" type="u"/>
    </signal>
    <signal name="Finished"/>
</interface>

Progress signals are not emitted unless there's at least one
D-Bus client expressed an interest by calling EnableUpdates
with appropriate flags. Request for updates can be revoked
with DisableUpdates. This complicates things a bit but I think
it's worth the trouble.

See merge request !9