Fixes crashes around OCSP with FetchSM

[maskit]

We saw two kind of crashes while testing #9591 and #9624, and the both were triggered by OCSP request timeout. In a nutshell, the crashes are due to accessing unavailable continuations. Continuations become unavailable when OCSP requests timeout, but the status were not properly updated/checked.

[ywkaras]

Looking at this:

wkaras ~/REPOS/TS
O$ grep -e '\Wfetch(' -e '\Wset_done(' -e '\Wset_error(' $(findsrc)
./include/tscore/ArgParser.h:  void set_error(std::string e);
./iocore/net/OCSPStapling.cc:      this->fetch();
./iocore/net/OCSPStapling.cc:        req->set_done();
./iocore/net/OCSPStapling.cc:        req->set_error();
./iocore/net/OCSPStapling.cc:  fetch()
./iocore/net/OCSPStapling.cc:  set_done()
./iocore/net/OCSPStapling.cc:  set_error()
./plugins/experimental/inliner/cache.h:  fetch(const std::string &k, A &&...a)
./plugins/experimental/slice/prefetch.cc:  if (bg->fetch(data)) {
./plugins/experimental/slice/prefetch.cc:BgBlockFetch::fetch(Data *const data)
./plugins/experimental/slice/prefetch.h:  bool fetch(Data *const data);
./plugins/lua/ts_lua_fetch.c:  /* ts.fetch() */
./src/tscore/ArgParser.cc:ArgParser::set_error(std::string e)
./src/tscore/unit_tests/test_ArgParser.cc:  parser2.set_error("error");
wkaras ~/REPOS/TS
O$

it's clear that fetch(), set_done() and set_error() are only called by event_handler(). So, the continuation mutex will already be locked when they are called. It also means these member functions should be private. I suggest you make them private as a part of this PR.

[ywkaras]

In event_handler(), won't req always be the same as this? What's the point of it then?

[maskit]

I made the functions private and removed unnecessary calls for ext_set/get_user_data.

So, the continuation mutex will already be locked when they are called.

This may be true, but I kept SCOPED_MUTEX_LOCK, which should be almost no-op if the lock is acquired. Because e->mutex and e->continuation->mutex can be different under some conditions and e->continuation->mutex is not locked in that case. It may not be the case for this, but I'd rather explicitly acquire the lock.