Strict chaining may not be "strict" in multithreaded scenarios

Suppose we have threads T1 and T2, both using a strict proxychain of proxy servers A, B, and C in that order. Further suppose that T2's execution closely follows T1's. It could happen that T1 has just finished connecting and set the proxy to the BUSY_STATE, when T2 is scheduled to run. When T2 does select_proxy it will get B because A is not in the play state. T2 will not know what the first proxy in its chain has been skipped nor that "strict mode" has been violated. This could also happen in non-multithreaded situations. For instance, if a signal handler is invoked from within hooked connect and the signal handler calls connect.

I see several solutions:

1. Do nothing and note that this may not work as expected with multiple threads.
2. Put a big lock around the STRICT_TYPE case in connect_proxy_chain. But that could make for very long connect times with many threads or many proxies in the chain.
3. Have proxy state be a thread local variable. This will be a non-trivial amount of work though, since we can't declare the state property in the struct to be thread local.
4. Make a copy of the global chain list on connect and use the copy. This is fairly simple to implement, but it seems like a waste of bytes and cpu.
5. Remove the state variable from the proxy_data struct and create a state list in connect_proxy_chain. Means lots of code changes.

I think option 2 is worse than option 1 and should be avoided.

Start by reading connect_proxy_chain, select_proxy, and the STRICT_TYPE handling, then inspect how proxy_data state is shared during connect and reentrant calls. Compare the proposed locking, thread-local, copied-chain, and separate-state approaches; done means strict chains cannot silently skip a proxy during concurrent or nested connects.