Fix "Merge trackers" always emitting failure

[alainbryden]

• handleDuplicateTorrent should only emit addTorrentFailed if merging is disabled, or prevented (due to either torrent being private)
• handleDuplicateTorrent should return a success code, and callers need to be updated to not always assume failure.
• While GUI doesn't do much with the success code - processTorrent should also be returning true when a duplicate is handled (either via the dialog, or via handleDuplicateTorrent - previously it always returned false)

Closes #23367
Closes #21821

---

Disclaimer: This is my first PR, I don't have a working local build yet, so I'm counting on CI to catch any errors. Any help testing would be appreciated.

[glassez]

• handleDuplicateTorrent should only emit addTorrentFailed if merging is disabled, or prevented (due to either torrent being private)

No. It is intended to emit addTorrentFailed unless new torrent is added. Receiver is responsible for handling it depending on failure reason.

[alainbryden]

No. It is intended to emit addTorrentFailed unless new torrent is added. Receiver is responsible for handling it depending on failure reason.

If this is true, can we take a step back for a minute and challenge this intention?

When an end-user (or API) requests to add a torrent, I think we can agree that what they want to ensure is that the files the torrent describes are being downloaded via the trackers and seeds the torrent specifies, that is all.

If merging torrents is allowed, and the result of adding the torrent is a merge operation, then the adding of that torrent has succeeded.

I think it would be quite an anti-pattern to force all existing usages monitoring the "addTorrentFailed" socket to now have to start parsing the response to see if the reason message "Trackers are merged from new source", and not generate an error notification in such instances, e.g. here:

qBittorrent/src/app/application.cpp

Lines 932 to 937 in 518fd7c

	connect(m_addTorrentManager, &AddTorrentManager::addTorrentFailed, this
	, [this](const QString &source, const BitTorrent::AddTorrentError &reason)
	{
	m_desktopIntegration->showNotification(tr("Add torrent failed")
	, tr("Couldn't add torrent '%1', reason: %2.").arg(source, reason.message));
	});

---

If you only want to emit torrentAdded when a new, distinct torrent is added, I can get behind that, and have updated my pull request with that alternative.

But I believe based on all current usages that torrentFailed should only be emitted when the add request accomplished nothing, and an error notification / response is warranted.

If you require something to be emitted, then the most correct thing to do here is to add a new event addTorrentMerged, and wire it up accordingly. I suspect that all or most usages will treat this the same as torrentAdded rather than as addTorrentFailed, if they need to hook it at all.

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.

[alainbryden]

Bump