ITS#10164 back-meta hangs when used with dynlist overlay

Make sure every proxied operation has a separate candidates structure When an overlay issues an internal operation on receiving an entry from a previous operation, back-meta hangs in an endless thread_yeald cycle. This happens because back-meta uses a single candidates structure per thread to hold operation status. In the above case, it ends up proxying two operations simultaneously in the same thread, and the second operation corrupts the state for the first. This patch ensures that every operation has a separate candidates structure to maintain the state. This problem seems to have been there from the start, but is only discovered because dynlist starts an internal search for every group entry received for the original request - the problem will not appear if the internal op is started when the client op is received (on the way down), because in such cases the two operations are executed by meta consecutively and they do not mess up each other's data.

I would like the reviewers' opinion - originally meta used the thread context to store that data. I am not sure why this is a good approach, but I kept it, making sure to use the op as a key, so that each op has it's own. As I understand the number of keys is limited to MAXKEYS, potentially limiting the number of concurrent ops executed by a single thread inside meta. It seems to me extremely unlikely to have such a large number, but it is possible alternatively to hold the candidates in op_extra instead.