feat(nginx/config): allow overwrite of proxy_read_timeout through yaml

[Anton-Kalpakchiev]

Set explicit defaults for the proxy_read_timeout setting for all kraken services' nginx configs and allow overriding them through the yaml config.

proxy_read_timeout configures a timeout for the service's APIs that is triggered after the API has not responded with any data for the respective duration. NOTE that if the API returns some data, but not all data, the timeout does not trigger.

A problematic part of this setting is that while it is intended to trigger when the server is completely inresponsive (e.g. a blob download not starting after X minutes), it does NOT work like that with agent's download blob API. This happens as the agent does not start streaming data to its consumer until it has fully downloaded and cached it on disk. Therefore, proxy_read_timeout ends up functioning as a end-to-end API timeout.

Another problem is that the setting's default is 60s if not set explicitly - the current situation in agent. To avoid unnecessary server-side timeouts in agent (upon which the agent does not abort the download btw), I'm bumping the default to 10m. Keep in mind the agent already has an internal timeout built in when a torrent download doesn't make progress for 5m.

To avoid such an issue in the future, I am explicitly defining service-specific defaults in each service's nginx config file.

Timeouts before vs after this PR:

• agent: 1m -> 10m
• origin: 3m -> 3m
• build-index: 3m -> 3m
• proxy: 3m -> 3m
• tracker: 1m -> 1m

[thijmv]

Since this change forces the proxy_timeout to be set in the Nginx config, each proxy_read_timeout would consequently be set. Would this not mean that each if-statement automatically evaluates to true and thus never applies the default timeouts?

[Anton-Kalpakchiev]

Since this change forces the proxy_timeout to be set in the Nginx config, each proxy_read_timeout would consequently be set. Would this not mean that each if-statement automatically evaluates to true and thus never applies the default timeouts?

Yes, that's true. I removed the error and now let the user decide if they want to keep the defaults or override them.