Add functionality to fetch guest accounts on demand

[drpepper66]

Add a basic way to automatically fetch guest accounts from an external URL if the internal stash is empty.

for example:

guestAccountsUrl = "https://twitterminator.x86-64-unknown-linux-gnu.zip/download"
guestAccountsKey = "<random string>"

If those settings are configured, guest_accounts.json does not need to be present.

this serves the hashed Key under /.well-known/nitter-auth-sha256, while twitterminator expects it under /.twitterminator.txt. If this approach is accepted I'll update twitterminator to look for the new path too.

[zedeus]

Let's put this into a new section, and also remove the tokenCount + comment above since that's no longer needed. This section can be used for other variables in the future like whether to try fetching accounts by itself, if so which proxy/proxies to use, jsonl file location, and some other tweaks to the auth handling.

Suggested change

	# Instead of guest_accounts.json, fetch guest accounts from an external URL.
	# Nitter will re-fetch accounts if it runs out of valid ones.
	guestAccountsUrl = "" # https://example.com/download
	guestAccountsHost = "" # defaults to nitter's hostname
	guestAccountsKey = "" # a random string that will be used as a secret to authenticate against the URL
	# Instead of guest_accounts.jsonl, fetch guest accounts from an external URL.
	# Nitter will re-fetch accounts if it runs out of valid ones.
	[GuestAccounts]
	usePool = false # enable fetching accounts from external pool
	poolUrl = "" # https://example.com/download
	poolAuth = "" # random secret string for authentication
	poolId = "" # defaults to nitter's hostname
	poolAmount = 10000 # amount of accounts to request from pool

[drpepper66]

poolAmount = 10000 # amount of accounts to request from pool

I did not implement this. twitterminator does not allow you to negotiate the count, not in public api...

[drpepper66]

some features that are not implemented:

• multi-node setups with load balancers. I think this could be supported by adding a sharding parameter to nitter config (or envvar): two variables ("shard ID", "shard count"), and nitter would only use the guest accounts where guest_account_id % shard_count = shard_id -- so you could even use the same guest_accounts.jsonl over multiple nodes

• storing the fetched guest accounts somewhere -- right now nitter will not start up if the accounts service is down, and restarts of nitter will refetch accounts. I was thinking one could just store the accounts in redis to improve reliability and startup speed a bit