QWizard: give all buttons an objectName

Only Commit, Finish and Cancel didn't have an object name, yet.
Also Extract Method on the switch statement, add a test, and
use QStringBuilder.

Task-number: QTBUG-29924
Reported-by: Leo Arias

Change-Id: I8c29606bc53e9d4caab631da2089e971a9da2d75
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
(cherry picked from qtbase/1ea191276ea49ce2334d21b1f4a2c66ee8889466)
QWizard: provoke 'enum value not handled in switch' warnings in object_name_for_button

This is strictly speaking a behavior change, since we're no longer returning
something for Stretch and NoButton, but - guessing here - that shouldn't matter.
Yet, better safe than sorry, thus submitted as a separate patch.

Change-Id: I20cb084147f8c9257ce37d1e87ea38febabec28d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
(cherry picked from qtbase/269590516d89a35ea3121366f7d4bf43b0d391ca)
QThreadPool: fix typos

Task-number: QTBUG-31919
Backport from qtbase/37dc44d499884bd0d7ab9d2f1547db468c9fe53b

Change-Id: I9496b059ed201da6b7a5ec02c4acb8f231e40c30
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QThreadPool: fix data races in activeThreadCount()

Rather than trying to make it lock-free (which requires double-bookkeeping of
4 atomic ints!), just lock the mutex before calling it.
tst_bench_qthreadpool shows no difference whatsoever between the two
solutions, I get 0.005 msecs per iteration in startRunnables().

Of course looping over calls to activeThreadCount() is a bit slower,
from 0.0002 msecs per iteration to 0.00027 msecs, i.e. 35% more.
But polling activeThreadCount() from the app is a really wrong thing to
do anyway, this benchmark was just for my own curiosity about the
price of a mutex in a function that sums up 4 ints.
What matters is start() performance, which is unchanged (0.00007 msecs
is just noise compared to a 0.005 total, that's 1.4%).

Backport from qtbase/85b24bb2dea97c3a9b013bacd5a422b26fe5d14b

Change-Id: Id32791069bc1e2dd61cef708d5287c9f9b7e5582
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QThreadPool: fix counting of waiting threads

QTBUG-21051 has a testcase where activeThreadCount() could actually
end up at -1 (converted to an autotest in this commit).
The reason was: start() calls tryStart() which returns false due to
too many active threads (reserveThread() causes this), so it calls
enqueueTask() - which actually wakes up the waiting thread, but
it didn't decrement the number of waiting threads.

Note that tryStart() is "if I can grab a waiting thread, enqueue task and wake it"
while start(), in case tryStart() fails, wants to "enqueue, and then if I can grab
a waiting thread, wake it". This is why enqueue shouldn't wake; waking must happen
only if we can grab a thread (d->waitingThreads > 0).

Task-number: QTBUG-21051
Backport from qtbase/dacf9961da86751a59da0e84bc943fe0d1c8d95b

Change-Id: I1e437da27b733a72b48ff1b6f2b78f81a7ed129b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QThreadPool: fix race at time of thread expiry.

The current synchronization mechanism was racy: decrementing waitingThreads
and then hoping that the wakeOne will wake a thread before its expiry
timeout happens. In other words, on timeout, a just-assigned task would
never run. And then no other task would run, if maxThreadCount is reached.

Fixed by using a queue of waiting threads (rather than just a count), and by
moving the wait condition into the thread itself, so we know precisely
which one we're waking up, and we can remove it from the set of waiting threads
before waking it up, and therefore it can determine on wakeup whether it
has work to do (caller removed it from the queue) or it expired (it's still
in the queue). This is reliable, whereas the return value from QWaitCondition::wait
isn't reliable, when the main thread has already decided that this thread
has work to do.

Task-number: QTBUG-3786
Backport from qtbase/a9b6a78e54670a70b96c122b10ad7bd64d166514

Change-Id: Ic766ff67dea7a8bb8f1bc893943060ee5428d782
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When reparenting a widget, children need to reregister as a drop site

If a widget is a drop site and an ancestor gets reparented then the
widget needs to be reregistered as a drop site so that it is correctly
associated with the new native parent widget.

Task-number: QTBUG-30276

Change-Id: I440077e54f614d0bfbaef46104de6598411c986b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>