WS_Reset() and overflown workspaces

[nigoroll]

noticed here: b12af68

We use workspace overflows to signal to bail out for example after a failing VRT_SetHdr(). This is a guarantee that if some serious issue occurred during processing, we rather send an error downstream than an incomplete response or the result of incomplete processing.
We use the WS_Snapshot() ... WS_Reset() pattern as some kind of second order workspace allocation where the called code itself uses WS_Reserve().
This combination is problematic because WS_Reset() calls ws_ClearOverflow(ws), potentially clearing the overflow bit from a previous relevant failure.

I think we should simply forbid WS_Snapshot() on overflown workspaces, mandating prior calls of WS_Overflowed() for the above mentioned pattern.

Feedback welcome

[nigoroll]

this patch to c00071.vtc demos the issue. Notice that the vtc already failed in the wrong place (while pushing processors rather than in the regsub()), which remained unnoticed.

diff --git a/bin/varnishtest/tests/c00071.vtc b/bin/varnishtest/tests/c00071.vtc
index 7e3c156ee..d4c17de1b 100644
--- a/bin/varnishtest/tests/c00071.vtc
+++ b/bin/varnishtest/tests/c00071.vtc
@@ -13,6 +13,7 @@ server s1 {
 
 varnish v1 -vcl+backend {
        import vtc;
+       import std;
        sub vcl_deliver {
                vtc.workspace_alloc(client, -192);
 
@@ -21,7 +22,8 @@ varnish v1 -vcl+backend {
                        vtc.workspace_alloc(client, -10);
                }
                else if (req.url ~ "/baz") {
-                       set resp.http.x-foo = regsub(req.url, "baz", "baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaz");
+                       set resp.http.x-foo = regsub(req.url, "baz", "baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaz");
+                       std.log("dummy");
                }
                set resp.http.x-of = vtc.workspace_overflowed(client);
        }

result:

**** c2   http[ 0] |HTTP/1.1
**** c2   http[ 1] |200
**** c2   http[ 2] |OK
**** c2   http[ 3] |Content-Length: 0
**** c2   http[ 4] |Date: Mon, 20 Jan 2020 13:41:33 GMT
**** c2   http[ 5] |X-Varnish: 1006
**** c2   http[ 6] |Age: 0
**** c2   http[ 7] |Via: 1.1 varnish (Varnish/6.3)
**** c2   http[ 8] |x-of: false
**** c2   http[ 9] |Accept-Ranges: bytes
**** c2   http[10] |Connection: keep-alive
**** c2   bodylen = 0
**   c2   === expect resp.status == 500
---- c2   EXPECT resp.status (200) == "500" failed

[nigoroll]

FTR, I just noticed that we already had a similar issue in #2645