SC_*_WS_OVERFLOW / PROXY2 tlv overflow causes obscure diagnostics

[bsdphk]

After updating hitch on v-c.o, github webhooks failed via https.

It would be generous to describe the resulting diagnostics as obscure.

In github's end all you see is "We couldn’t deliver this payload: No error"

In varnishlog I get:

 295244 Begin          c sess 0 PROXY
 295244 SessOpen       c 10.0.0.202 54523 a1 10.0.0.100 444 1578303689.314196 34
 295244 Proxy          c 2 192.30.252.97 26095 10.0.0.202 443
 295244 SessClose      c OVERLOAD 0.049
 295244 End            c 

I realize that the length of some of the tlv's may be under an attackers control, but I would still expect some hint that maybe I have a misconfiguration and something pointing in the direction of the session workspace ?

[nigoroll]

So is 287dc4a6745c374e0b229bfa861d664989a3a9e8 insufficient or are you running older code?

[nigoroll]

also related: #3145

[bsdphk]

Thinking about this, and our approach to possible-DoS-situation logging:

Maybe we should log details for the first incident, then start at timer of one minute ($param) and not report details again until that timer expires.

That way people debugging will get their info, but DoS attacks will not stuff the logs.

[bsdphk]

bug-pow-wow sorta-consensus: Maybe we need SC_SESSION_WS_OVERFLOW, SC_CLIENT_WS_OVERFLOW etc...

[nigoroll]

pow wowed again:

• SessClose docs in include/tbl/vsl_tags.h need TLC regarding the Why (sess_close_2str() that is)
• We might want to add something similar to strerror()

[bsdphk]

Split SC_OVERLOAD into different ones which say what we ran out of