Added missing options in amuleweb-main-prefs.php options apply - #414

…ct#414)

On a remote GUI first sync, the download list was populated one partfile
at a time, and CDownloadListCtrl::AddFile() re-sorted the entire list on
every insert. For a large queue that is O(n^2*log n): the reporter's 10k
downloads took ~20 min to load with the GUI frozen the whole time.

Port the fix the shared-files view already uses (the m_initialUpdate
flag): during the initial bulk load, defer the per-item show + sort and
only build the model entries, then show and sort the whole list once via
the new CDownloadListCtrl::ShowFileList() (Freeze + a single SortList +
Thaw), mirroring CSharedFilesCtrl::ShowFileList().

AddFile() gains a deferView parameter (default false), so the normal
single-add path (GuiEvents.cpp) and every incremental update are
unchanged; only the first full sync defers.

Refs amule-project#414

…ct#414) (amule-project#415)

On a remote GUI first sync, the download list was populated one partfile
at a time, and CDownloadListCtrl::AddFile() re-sorted the entire list on
every insert. For a large queue that is O(n^2*log n): the reporter's 10k
downloads took ~20 min to load with the GUI frozen the whole time.

Port the fix the shared-files view already uses (the m_initialUpdate
flag): during the initial bulk load, defer the per-item show + sort and
only build the model entries, then show and sort the whole list once via
the new CDownloadListCtrl::ShowFileList() (Freeze + a single SortList +
Thaw), mirroring CSharedFilesCtrl::ShowFileList().

AddFile() gains a deferView parameter (default false), so the normal
single-add path (GuiEvents.cpp) and every incremental update are
unchanged; only the first full sync defers.

Refs amule-project#414

…oject#478)

aMuleGUI's lists (Downloads, Shared, Searches, servers/Kad) are the generic
custom-drawn wxGenericListCtrl, not the native ListView. On Windows the view
leaves rows unpainted when it scrolls without a full invalidation: entire lines
go blank on mouse/scrollbar scroll and on HOME/END/PgUp/PgDn, reappearing only
on select, CTRL+A, or a scroll back. The mouse/scrollbar case regressed
recently (clean on 3.0.1 stable per the reporter); the keyboard case is a
longer-standing wxMSW quirk.

Enable double-buffering on the CMuleListCtrl base (WS_EX_COMPOSITED on wxMSW),
which paints the control and its inner list window through an off-screen
buffer, so every scroll repaints the whole viewport. Scoped to __WXMSW__ --
macOS/GTK already double-buffer. This fixes the paint without touching the
Freeze()/Thaw() bulk-load batching (amule-project#414), which stays for its perf win.

Refs amule-project#478

* fix(gui): don't reuse ECIDs across a daemon restart

An ECID only means something within one daemon process. CECID hands them
out from a counter that restarts with the process, so a restarted amuled
reissues the same numbers, in whatever order it loads files that time.
amulegui deliberately keeps its objects across a reconnect so scroll and
selection survive (amule-project#444), and reconciles the fresh snapshot against them by
ECID -- which after a restart pairs each object with whatever now happens to
share its number. The row survives and is quietly overwritten with a
different file's name, size and statistics, and if the class no longer
matches it also ends up in the wrong list.

It can also crash. CKnownFilesRem::ProcessItemUpdate copies the part-status
array using two bounds from different places: the buffer is as long as the
decoder made it from what arrived, while GetPartCount() is the object's own,
derived from the size it currently believes the file to be. They agree for
as long as an ECID keeps meaning the same file. Paired with a file of a
different size the loop reads off the end of the heap allocation, which is a
good fit for the 0xc0000005 in issue amule-project#884.

The daemon now identifies its process in AUTH_OK via EC_TAG_SESSION_ID, and
a reconnect compares it. Same value means the socket dropped but the daemon
lived -- a sleeping laptop, a dead tunnel -- so the in-place reconcile is
right and scroll and selection still survive. A different value, or none at
all because the daemon predates the tag, means nothing keyed by ECID can be
trusted, and every such container is dropped and repopulated from the next
poll. That fallback is what makes this work against daemons already
deployed, which is the case the reporter is in.

The teardown goes through RemoteContainer::ResetForNewSession(), which drops
items one at a time through the existing RemoveItem/DeleteItem path rather
than clearing the indices: that path fires the destroy broadcast that makes
clients and list controls drop their raw pointers (amule-project#748, amule-project#755), removes the
rows from the views and then deletes. CKnownFilesRem also re-arms the
cold-boot path so the repopulate is batched through ShowFileList() instead
of sorting once per inserted row (amule-project#414).

The part-status copy is bounded and its tail cleared regardless. Two bounds
from different sources should never be assumed to agree, and leaving the
tail would show the previous file's availability under the new one's name.

* fix(gui): report a part-status length mismatch instead of only clamping

The clamp on its own is silent, and with the session check in place the only
way it can now trigger is if that check failed to notice the daemon changed
underneath us. That is worth knowing about: clamping leaves no other trace,
and the rest of the update goes on applying the same mismatched tag to the
same object, so the visible result would be a row quietly describing the
wrong file rather than anything that points at the cause.

* fix(gui): warn the user when the remote core sends inconsistent file data

A debug line was the wrong level for this. It only appears with EC debug
logging enabled, which almost nobody turns on, so in the field it would have
reported the problem to nobody -- and the problem is one the user can both
see and act on: the clamp keeps the copy in bounds, but the rest of the
update goes on applying a mismatched tag to the same object, so what they
end up looking at is a row describing the wrong file. Reconnecting clears
it, which the message now says.

Once per session rather than once per file. The check sits in a loop that
covers the whole library on every poll, and the condition it reports is
library-wide when it happens at all, so at critical level the per-file form
would have put thousands of bold lines in front of the user.

Regenerates the po catalogs for this string and for the reconnect notice
added earlier on this branch.

* fix(gui): drop a null guard that only taught the analyser to doubt m_connect

Startup() only runs on a successful connect, and the lines just below take
CStatistics(*m_connect) and CStatTreeRem(m_connect) unconditionally, so a
null m_connect is already undefined behaviour there. Testing it before
reading the session id therefore guarded nothing -- but it did assert that
the pointer is optional, and Tier-1 clang-tidy read it exactly that way:
having seen the null branch it reported the dereference below as reachable
with null (clang-analyzer-core.NonNullParamChecker), failing CI on a line
this change never touched.

The guard in FinishReconnect() stays. Nothing else in that function
dereferences m_connect, so it creates no such branch, and falling back to 0
there means "cannot tell which daemon this is", which selects the safe
start-over path rather than papering over anything.