cmake: keep wx_NEED_NET on for BUILD_WEBSERVER-only configurations - #620

…nnect (amule-project#620)

Adding a burst of downloads to a large queue over the remote GUI froze the
GUI for seconds and dripped the new files in at only a few per second
(issue amule-project#615). Selecting ~100 search results for download on a ~10k queue
was the reporter's repro.

CKnownFilesRem::ProcessUpdate() only wrapped the list ctrls in
BeginBatchUpdate()/EndBatchUpdate() for the post-reconnect reconcile
(issue amule-project#444). On an ordinary steady-state poll the batch was never
engaged, so each freshly-added partfile went through
CDownloadListCtrl::AddFile() with the per-item SortList() active: a full
re-sort of the entire list on every insert. For a 10k queue that is
O(n^2 log n) and blocks the GUI event loop, which in turn throttles the
outbound download requests -- hence the ~4/sec drip the reporter saw.

Batch the download list on every non-initial poll: BeginBatchUpdate()
suppresses the per-item sort, and the single SortList() runs once at the
end, and only when the poll actually added a file (downloadListGrew). A
pure in-place stat poll stays sort-free, so the common case pays nothing.
EndBatchUpdate() gains a doSort parameter (default true) to express that.
The cold-boot m_initialUpdate path keeps its own ShowFileList() batching
and is left untouched. The shared-files ctrl batching is unchanged
(reconnect-only), matching its existing behaviour.

Refs amule-project#615

amule-project#621)

Downloading a large multi-selection of search results into a big queue
froze the monolithic GUI, the same way amule-project#615 did over the remote GUI --
just on a different, un-batched path.

CSearchListCtrl::DownloadSelected() loops over the selection calling
Search_Add_Download per file. In the monolithic build that notification
runs synchronously on the main thread, so each file's AddFile() fires a
per-item SortList() inline -- a full re-sort of the whole download list
on every insert, O(n^2) on a large queue.

Wrap the selection loop in the download list's BeginBatchUpdate() /
EndBatchUpdate() so the burst collapses into a single sort + repaint,
mirroring the remote GUI's poll path (amule-project#620). Monolithic-only: the remote
GUI's adds arrive later via the download-queue poll, which already
batches, so the code is gated behind #ifndef CLIENT_GUI.

…reconnect (amule-project#622)

Companion to amule-project#620/amule-project#621. Adding a burst of freshly-shared files over the
remote GUI -- many downloads completing daemon-side, or a shared folder
added/rescanned on the daemon -- froze the GUI on a large share. amule-project#620
fixed the equivalent download-list case but deliberately left the
shared-files ctrl batched reconnect-only.

CKnownFilesRem::ProcessUpdate() adds each new shared file via
CSharedFilesCtrl::ShowFile() -> AddItemData(), which on this virtual list
does a sorted insert AND rebuilds the entire row index (RebuildRowIndex)
on every call -- O(n) per insert, O(n^2) for a burst on an n-file share.
Unlike the download list, a plain Freeze/deferred-sort batch wouldn't
help, because the per-insert cost is the row-index rebuild, not a sort.

Give the shared-files ctrl the same append-path batching the download
list already uses: during a batch, ShowFile() appends with
AppendItemDataNow() (O(1), and it keeps the row index and item count live
so the interleaved reconcile prune and in-place UpdateItem() stay
correct), and the single SortList() is deferred to EndBatchUpdate(doSort).
The non-batch single-add path is unchanged. ProcessUpdate() now batches
the shared list on every non-initial poll and sorts once at the end only
if the poll added a file (sharedListGrew).

Monolithic is unaffected: its bulk shared paths funnel through the
batched Reload() -> ShowFileList(), and the dir-watcher coalesces bursts
into a single Reload(). Verified by building amule and amulegui.