Don't crash if the relayed signal was emitted from the wrong thread

Under normal circumstances, this should never happen. Signals exported
to D-Bus should only be emitted from the object's own thread. That's the
only way for the receiver (the QDBusAdaptorConnector object) to know
what the sender object and signal were. If they are emitted from another
thread, the sender will be null.

Task-number: QTBUG-31932
Change-Id: Ia5a45d648985e0645bffd4abc0881fca9da64f79
(cherry-picked from qtbase commit d94961d08f91696824d9035f666af5fe28d59ef6)
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDBusPendingCall: add a missing QWaitCondition::wakeAll() call

In QDBusConnectionPrivate::waitForFinished(), threads that see
pcall->waitingForFinished == true go to sleep on
pcall->waitForFinishedCondition, but there was no call to
waitForFinishedCondition.wakeAll() anywhere in the code, so add it.

Change-Id: I8d068dc0cc4f20786eb40fd7e2bb9840d8b70c7f
(cherry-picked from qtbase commit 20d7763b19400c062a07f440cc601f486be4039b)
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fix unprotected access to QDBusPendingCallPrivate::pending.

In QDBusConnectionPrivate::waitForFinished() pcall->pending was used
after the protection by pcall->mutex was released. A simultaneous
call to QDBusConnectionPrivate::processFinishedCall() was able
to reset pcall->pending to null before it was used for the
q_dbus_pending_call_block(pcall->pending) call.

Fixed by releasing (and setting to 0) of pcall->pending in
processFinishedCall() only in case no one is waiting yet, otherwise
release pcall->pending by the first thread waiting in waitForFinished().

There is still a race condition about deleting QDBusPendingCallPrivate
(too early) which will be fixed in the next two commits.

Task-number: QTBUG-27809
Change-Id: I040173810ad90653fe1bd1915f22d8dd70d47d8c
(cherry-picked from qtbase commit 64e3bd481e5d54d555959ceecbd5c4576c571241)
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove QDBusPendingCallPrivate::autoDelete logic.

First step to fix race condition about deleting QDBusPendingCallPrivate.

In a multithreaded application on a slow/single core cpu the following
race (and segmentation fault) can occur:

First thread A is running:
A:  QDBusPendingReply<> reply = pi->asyncCallWithArgumentList(method, argumentList);

Then when the dbus answer arrives thread B will call:

B:  QDBusConnectionPrivate::processFinishedCall()
B:      ...
B:      locker.unlock()

and runs until here, go on with thread A:

A:  reply.waitForFinished();
A:    QDBusPendingCallPrivate::waitForFinished()
A:    {
A:        QMutexLocker locker(&mutex);
A:        if (replyMessage.type() != QDBusMessage::InvalidMessage)
A:            return;

which returns immediately (mutex acquired, replyMessage alread set), now
reply goes out of scope (destructor called) and QDBusPendingCall::d's
destructor of type QExplicitlySharedDataPointer<QDBusPendingCallPrivate>
deletes the reference counted object QDBusPendingCallPrivate.

Now thread B continues, still in processFinishedCall()

B:      if (call->watcherHelper)
B:          call->watcherHelper->emitSignals(msg, call->sentMessage);
B:
B:      if (msg.type() == QDBusMessage::ErrorMessage)
B:          emit connection->callWithCallbackFailed(QDBusError(msg),
B:              call->sentMessage);

accessing alread deleted object QDBusPendingCallPrivate via call->...

Fixed QDBusPendingCallPrivate deletion by proper reference counting
will be done in the next commit.

Task-number: QTBUG-27809
Change-Id: I15b3f0242471b62eaafadc763fb6a33339ff2fe1
(cherry-picked from qtbase commit 72ecf5a7ecb688a7e19cbc2f70e358a94d02edf7)
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change QDBusPendingCallPrivate to full reference counting for deletion.

Fixes race between QDBusConnectionPrivate::processFinishedCall()
releasing the mutex before emitting signals (using various members of
QDBusPendingCallPrivate) and deletion of the QDBusPendingCallPrivate
object through QDBusPendingCall::d's destructor (a member of type
QExplicitlySharedDataPointer<QDBusPendingCallPrivate>) leeds to
segmentation fault with CrashTest example on slow/single core
arm cpu).

Task-number: QTBUG-27809
Change-Id: I3590d74d1cfa5816ede764b50b83a7008ec780ff
(cherry-picked from qtbase commit 6c21f42657b494e24112c90d8b9fff719f1f8791)
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QHttpMultiPart: fix data corruption in readData method

When readData() is called repeatedly, we need to keep track which
part of the multipart message we are currently reading from.
Hereby we also need to take the boundary size into account, and not
only the size of the multipart; otherwise we would skip a not
completely read part. This would then later lead to advancing the
read pointer by negative indexes and data loss.

Task-number: QTBUG-32534
Change-Id: Ibb6dff16adaf4ea67181d23d1d0c8459e33a0ed0
Reviewed-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
(cherry picked from qtbase/af96c6fed931564c95037539f07e9c8e33c69529)
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>