feat: add option debug to conf headers to disable kong_debug header function

[oowl]

Summary

add option debug to conf headers to disable kong_debug header function

Checklist

Full changelog

• introduce option debug to conf headers to disable kong_debug header function

Issue reference

FTI-4521

[chronolaw]

Should we add a change log entry for this new config item?

[chronolaw]

I think we need a change log entry for it.

[bungle]

I suggest we add debug option here:
https://github.com/Kong/kong/blob/master/kong.conf.default#L796

And not enable it by default, rather than introduce a new configuration option (perhaps even then only send these when requested with KONG_DEBUG request header).

[kikito]

I suggest we add debug option here: [...]

I agree with @bungle on this one. We already have too many config options. I'd rather modify headers to have a debug option.

[hbagdi]

I'm sympathetic to our situation of too many configuration options and I'm generally fully onboard with situations around reusing configuration properties. In this specific case, I'm -1 and recommend adding a new configuration field instead.

Here is my rationale:

1. While debugging, assume that the user doesn't know the default value of a configuration and wants to solve their problem with the least amount of friction. Assuming that, the user behavior will be to set "KONG_HEADERS=debug". And that will work, but suddenly you won't have other headers that you were probably relying on to debug your problem. The user is either going to be left puzzled or will successfully navigate their way around documentation to find that the property that they said needs two other values as well. This may seem like a minor inconvenience but details matter. Especially, when the user is frustrated.
2. Before this patch, 'headers' option controls headers that provide additional insight into request/response flows and provide some observability data. This configuration option doesn't modify the behavior of Kong based on input at proxy time. The debug header on the other hand only conditionally adds additional context to request/response headers. There is a small semantic difference between the two.

What do you all think?

[kikito]

I see both points that @hbagdi is saying.

It will be very easy to miss that instead of KONG_DEBUG=true you have to write KONG_HEADERS=server_tokens, latency_tokens,debug, which is error-prone and easy to forget.

I missed that this particular option will only act when the consumer request has the kong-debug=1 header set, while the others act in all requests (regardless of their headers). That makes it slightly different.

These two things separately would not change my opinion, but together they made me change my mind. Thank you, Harry.

@attenuation could you please restore this PR to its previous state, using a single global variable for debugging?. Apologies for the back-and-forth. (I would recommend keeping a local copy of this PR as it is - with headers just in case)

[oowl]

@kikito Hi Enrique, I have restored the code base to the old version, please help me review it

[kikito]

I'm preapproving this in case we are adding enable_debug_header because we cannot use debug_header directly. (Perhaps KONG_DEBUG_HEADER is already used for something else).

If we can rename it without issues, please rename it before merging.

If we must use something other than debug_header for some reason, then please merge as-is.