Rethink which timeouts should be configurable

[linkvt]

Proposal

We currently allow users to configure quite a few timeouts in a few different ways (some global, some overridable per HTTPSO).
These timeouts are often quite technical and might even leak internal implementation details like KEDA_HTTP_CONNECT_TIMEOUT or KEDA_HTTP_DIAL_RETRY_TIMEOUT.
The naming could also be improved for some others like KEDA_CONDITION_WAIT_TIMEOUT which doesn't state which condition we wait for.

We should consider the users perspective and requirements and derive the timeouts we want to expose based on that.
Something that isn't easy right now is configuring a simple timeout for the time the response from the backend service takes as you can only configure very fine granular timeouts right now.
We should also keep the coldstart failover timeout in mind.

Here is a list of the current timeouts and their function (might be outdated when you read this so make sure to check the code):

• KEDA_HTTP_CONNECT_TIMEOUT (500ms): Per-attempt TCP dial timeout — passed to net.Dialer.Timeout
• KEDA_HTTP_KEEP_ALIVE (1s): TCP keepalive probe interval — passed to net.Dialer.KeepAlive
• KEDA_RESPONSE_HEADER_TIMEOUT (500ms): Max wait for response headers from backend — set on http.Transport.ResponseHeaderTimeout via transport pool
• KEDA_CONDITION_WAIT_TIMEOUT (20s): Max wait for workload to scale to >=1 replicas — bounds the waitFunc context in the proxy handler
• KEDA_HTTP_IDLE_CONN_TIMEOUT (90s): Time before idle connections are evicted — http.Transport.IdleConnTimeout
• KEDA_HTTP_TLS_HANDSHAKE_TIMEOUT (10s): Max wait for TLS handshake — http.Transport.TLSHandshakeTimeout
• KEDA_HTTP_EXPECT_CONTINUE_TIMEOUT (1s): Max wait for 100-continue response from backend — http.Transport.ExpectContinueTimeout
• KEDA_HTTP_DIAL_RETRY_TIMEOUT (15s): Total time budget for dial retries — bounds the retry loop via context.WithTimeout

We should also consider choosing a consistent parsing approach, e.g. to not name fields xyzSeconds but use go parseable durations instead.

As this is likely a breaking change and quite a big topic, please provide a design document for discussion before implementing.

Use-Case

No response

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

No response