ServerSocket: bypass download bandwidth throttler for control traffic (#393) - #615

PR #615 added IsDownloadThrottled() with the override keyword on
CServerSocket. That made Clang's -Winconsistent-missing-override fire
on the existing CServerSocket overrides (OnClose / OnConnect /
OnReceive / OnError / PacketReceived / SendPacket) that were missing
the keyword. Reported by Stoatwblr on #622.

Add override to the affected six methods in CServerSocket, and apply
the same cleanup to CClientTCPSocket -- which has the identical
inheritance shape from CEMSocket and was one stray override keyword
away from triggering the same warning. Also drop the redundant
virtual keyword on the derived overrides (override implies virtual).

Build clean on macOS arm64; warning gone on the Linux build path
Stoatwblr was using.

…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.