Generic HTTP/API-key notification target (extends existing Network Notifications)

[seeb73]

Feature Description

QLog already has a generic real-time notification mechanism (Settings -> Network -> Notifications) that pushes JSON over UDP to whatever address the operator configures - it isn't tied to any single service, anyone can stand up a listener that speaks the format.

I'd like to propose the same idea over HTTP, for services that want the API key delivered as a login credential (POST body) rather than as a plain query parameter in a GET request - so the key never ends up sitting in a URL or an access log.

Concrete motivation: radiodyplom.pl, a Polish award/diploma tracking service for ham radio operators, runs a live-log feed that already receives hundreds of QSOs a day. For scale comparison, my own station currently pushes thousands of QSOs/day through the existing UDP Notifications to my own tooling - this class of feature clearly gets real, heavy use once it exists.

Proposed contract (two separate requests per logged QSO, deliberately):

1. POST {url} body apikey= - the secret never appears in a URL/access log.
2. GET {url}? - the QSO itself, as flat ADIF-named query parameters (same flattening AdiFormat::readContact() already produces on import). No API key here - if the server sets a session cookie on the POST response, QNetworkAccessManager's default cookie jar carries it into the GET automatically (the same login-then-act flow a browser would do).
   Both requests go through Qt's normal QNetworkAccessManager, so https:// is supported out of the box for both the login and the QSO upload - the endpoint URL is exactly what the operator configures, http:// or https:// alike, no separate switch needed. https:// is what actually makes the "key never in a URL/log" property meaningful end-to-end, so it's the expected real-world setup, not an afterthought.

The server decides how (or whether) to correlate the two requests; QLog wouldn't send any shared token/session id of its own beyond the above.

I already have a working implementation (core/QSOApiKeyQuery, core/QSOApiKeySender, wired into Settings -> Network the same way the existing Notifications are, with unit tests covering the query-flattening and the POST-then-GET flow against a fake HTTP server), on a branch cut from current master: diff (branch). Compiles and passes its tests on Linux, and I've also verified a full win64 and a universal macOS build against it. Happy to open a proper PR if this direction sounds reasonable, or to adjust the wire contract first if you'd rather it look different.

[foldynl]

Since there are many different server implementations for receiving QSOs, this is exactly why I implemented Notifications in QLog. Each service can implement its own bridge and handle any service-specific requirements there.

What you describe has several issues that make it unsuitable as a generic implementation in QLog:

1. The requirement to perform a POST/GET request before sending a QSO is highly server-specific. This cannot really be generalized because every service handles authentication differently. Yes, it would work nicely with your server, but it cannot be applied generically.

2. Your proposal is stateful. What should QLog do if the service is unavailable? How should it resend the QSO later? Should QLog maintain a separate persistent request queue for every service configured this way? What should happen when a QSO is updated? What about when it is deleted? And so on.

I don't think this kind of "generic" notification mechanism should be implemented directly in QLog.

The ideal solution would be to implement a dedicated UDP bridge for the particular service. The bridge can then implement the complete message flow, authentication, retry logic, and any other requirements specific to that HTTP server.