The reason is the same as for
https://github.com/varnishcache/varnish-cache/issues/2708 :

VRT_priv_task may now return NULL for out-of-workspace errors, see
https://github.com/varnishcache/varnish-cache/commit/de2b431086a13b243dc8b3e71cd8697db1df2c7f

If RE2 reports the "DFA out-of-memory" condition for a failed set
match, the VMOD reports the error as well.

Update REQUIREMENTS to reflect compatibility with Varnish 6.0.

re2 compatibility has been tested through 2018-04-01.

No longer using the auto-generated SYNOPSIS.

Fixes parallel build failures when compilation of vmod_re2.c,
set.c or re2.c is attempted before vmodtool is finished

The terminating null byte for the C string result is written at
the index given by std::string.size() for the C++ string. It had
been written at one past that index.

WS_Release() must then ensure that the terminating null byte is
within the allocated portion of workspace.

NULL is no longer possible as an ENUM value.

Ensure that the retrieved object was saved via set.add().

Checked with gcc/g++ and clang/clang++.

Otherwise builds can fail due to partially written files from vmodtool
running on another target.

vrt.h is included by cache.h, and may not be included after it.

Take advantage of the fact that the array of indexes returned from
the vre2 call is now sorted (but still using a linear search).