Doc: remove references to set-debug TXN_DEBUG in header_rewrite/hrw4u

[mlibbey]

The set-http-cntl TXN_DEBUG and (deprecated) set-debug need a non-overridable config (proxy.config.diags.debug.enabled) to be on. But, if its on, then you don't need header_rewrite to conditionally turn it on. (I suppose turning it off could be a use case, but, that would also require rewriting the docs).

[maskit]

Original discussion:
https://issues.apache.org/jira/browse/TS-1079

If I understand the original design correctly, the idea was that DebugSpecific() would work just like the old Debug() when not being "specific". But when enabled e.g. in a transaction or session, it would override the "global" defaults. So when the flag is true, it will always print the debug info, but when false it depends on whatever the global diags settings are.
The public TSDebugSpecific() API follows the same pattern as the core version I assume. Meaning, a plugin can now call TSDebugSpecific() in a way that it uses the global diagnostics settings when false, but forcing the Debug() when true. This seems generally useful to me.

This sounds like requiring the global setting to be enabled is a bug, but looks like even the initial implementation has the bug.
abf767e#diff-e0e00255e0c3acac2840eefc663f3fd3bc8c11bff8721a8f9a5e0c5521004153R294-R295

#define DebugSpecific(flag, tag, ...)  if (unlikely(diags->on())) flag ? diags->print(tag, DTA(DL_Debug), __VA_ARGS__) : \
                                                                    diags->log(tag, DTA(DL_Debug), __VA_ARGS__)

[maskit]

Another thing that should be noted is that majority of debug prints are not under the control of set-debug/TXN_DEBUG.

[zwoop]

Well, if we kill this feature in the docs (I'm fine with it, sounds like this stuff no longer works), we should also mark the underlying APIs and features in InkAPI etc. as deprecated for 10.2 so we can delete those too from v11.

[maskit]

I'm also fine with removing it. Nobody realized that it doesn't work as expected for a long time. The idea is nice if it works though.

[bryancall]

@moonchen will see if this feature can be fixed instead of just removing the documentation

[mlibbey]

I'm +1 on a working feature. Guess my question is... is the right approach to bring back the documentation if/when it is working (eg, with the PRs that make it work)?