`seqcli apikey create` with `--connect-username` fails over HTTP if the server's canonical URI is HTTPS

When SEQ_API_CANONICALURI is an HTTPS URL, Seq marks the username/password login authentication cookie with secure. This is intentional, we don't want to leave the secure flag off just because Seq is behind a load balancer and we didn't get the expected host or forwarding header.

In this situation, browsing Seq over a plain HTTP URL (e.g. http://localhost) still works because browsers appear to happily ignore this flag when the origin is an HTTP URL.

The .NET CookieContainer used by Seq.Api (and thus seqcli) is stricter, and won't send the auth cookie back if the next request is via plain HTTP, even if the cookie was itself received via plain HTTP.

Unfortunately, this interferes with initial provisioning scenarios where seqcli apikey create --connect-username= is used to create an API via localhost on a new/blank Seq server.

Since the cookie container used by seqcli is ephemeral, there's no browser involved, and the user has explicitly requested that it make a plain HTTP connection, the most appropriate fix is probably to loosen up the API client's cookie handling behavior only when the hostname is localhost or the loopback IP.

https://github.com/datalust/seq-tickets/discussions/2502#discussioncomment-14965142

Trace seqcli apikey create --connect-username= through the Seq.Api client and its .NET CookieContainer, then reproduce the failure with an HTTPS SEQ_API_CANONICALURI and an HTTP localhost connection. The fix should allow provisioning over HTTP only for localhost or loopback addresses while preserving secure-cookie behavior for other hosts.