Workaround found for go-nostr over tor

Having native tor support by ensuring all modules in hub support a configurable SOCKS5 proxy would be ideal. In lieu of that, we can at least get to tor using an http proxy - except for a [bug in go-nostr](https://github.com/fort-nix/nix-bitcoin/pull/794#issuecomment-4158809050):

> When Tor enforcement is enabled, Hub’s nostr relay connection fails behind an HTTP proxy because `go-nostr` takes a different websocket dial path **when a custom request header is set**; that path bypasses proxy-from-environment and attempts direct DNS/TCP egress. go-nostr's repo is archived, so my interim workaround is to stop setting the websocket `User-Agent` header in Hub (`service/start.go`), forcing `go-nostr` to use its default dial path that honors `HTTP_PROXY`/`HTTPS_PROXY` and restores nostr relay connectivity in nix-bitcoin.

Basically, go-nostr's DNS lookups don't traverse the http proxy when hub sets an http header `"User-Agent": {"AlbyHub/" + version.Tag},`, and fails immediately as a result. Many Bothans died to bring us this knowledge.

**Tor Enforcement**
nix-bitcoin uses composable nix modules. In a typical NB deployment, the `enable-tor.nix` module is used to enforce tor for all programs and services where possible. NB uses systemd to enforce tor network usage by using `IPAddressDeny=any` in service units. Here's the albyhub service unit when `tor.enforce` is enabled:

```
systemctl cat --runtime albyhub.service | grep -E '^Env|^IPAddress'
Environment="ALL_PROXY=socks5h://127.0.0.1:9050"
Environment="HTTPS_PROXY=http://127.0.0.1:8118"
Environment="HTTP_PROXY=http://127.0.0.1:8118"
...
EnvironmentFile=-/var/lib/albyhub/.env
IPAddressAllow=127.0.0.1/32
IPAddressAllow=::1/128
IPAddressAllow=169.254.0.0/16
IPAddressDeny=any
```

Small footnote: for go-nostr HTTP_PROXY must be an http proxy rather than a socks proxy because go-nostr does not support SOCKS5 proxies.

Anyway, the thrust of this issue is about shipping a version of hub that either works with http proxy by not setting the user-agent when an http proxy is detected, or maybe even forking go-nostr to add socks support. The reason socks support is still compelling is that the internal LDK node does not honor ALL_PROXY or work with an http proxy, so it is at odds with go-nostr and the boltz client about what proxy they want. The only way to specify both http proxy and socks proxy in env vars is using ALL_PROXY+HTTP_PROXY. The alternative there would be to add a direct configuration option in hub to configure a socks proxy for ldk-node, but I haven't looked deeply into what's involved yet. I personally use the nix-bitcoin LND instance. There's also the boltz client, but I forget if it supports socks or not. boltz client honors env var HTTPS_PROXY specifically, I think because it's connecting to an https service. Whereas in my observation, go-nostr uses HTTP_PROXY even for wss connections ¯\_(ツ)_/¯

So the downsides to using the workaround are that the LDK node still won't work, and nostr relay onion address still won't resolve. But on the other hand, it's a really small change compared to adding socks support.

Hope our findings are helpful. Love you guys! There was a guy that showed up to our meetup last week and talked about using Albyhub, which made us want to keep pushing to finish the nix-bitcoin module again.