type-context.h: Extent cancel_mutex lock to prevent theoretical race

As pointed out by janb84 in
bitcoin/bitcoin#34422 (comment) it makes
sense for the on_cancel callback to lock cancel_mutex while it is assigning
request_canceled = true.

The lock and assigment were introduced in bitcoin-core#240 and in an earlier version of
that PR, request_canceled was a std::atomic and the assignment happened before
the lock was acquired instead of after, so it was ok for the lock to be unnamed
and immediately released after being acquired.

But in the final verion of bitcoin-core#240 request_canceled is an ordinary non-atomic
bool, and it should be assigned true with the lock held to prevent a
theoretical race condition where capn'proto event loop cancels the request
before the execution thread runs, and the execution thread sees the old
request_canceled = false value and then unsafely accesses deleted parameters.
The request being canceled so quickly and parameters being accessed so slowly,
and stale request_canceled value being read even after the execution thread has
the cancel_mutex lock should be very unlikely to occur in practice, but could
happen in theory and is good to fix.

Author: ryanofsky

include/mp/type-context.h

@@ -123,7 +123,7 @@ auto PassField(Priority<1>, TypeList<>, ServerContext& server_context, const Fn&
                             // it. So in addition to locking the mutex, the
                             // execution thread always checks request_canceled
                             // as well before accessing the structs.
-                            Lock{cancel_mutex};
+                            Lock cancel_lock{cancel_mutex};
                             server_context.request_canceled = true;
                         };
                         // Update requests_threads map if not canceled.