BUG: Compute extent with multi-threading may influence fetching material bindings

[roggiezhang-nv]

We found a very strange behavior that ComputeExtent along with GetForwardedTargets in a multi-threading way would influence the behavior of getting material binding with API UsdRelationship::GetForwardedTargets. See the changes of this PR about the test to reproduce this. In the test, it's trying to traverse the whole stage with multi-threads. All operations are supposed to be read-only to the stage, and the test should be successful. However, it fails unexpectedly sometimes. Adding TfRegistryManager::GetInstance().SubscribeTo(); to the first line of main() will pass the test, which we still have no idea why.

You need to run the test with --repeat until-fail:1000 to increase the possibility of failure.

[roggiezhang-nv]

@nvmkuruc for vis.

[nvmkuruc]

On Linux, I had to use --repeat-until-fail 10000 to reproduce the failure.

[jesschimein]

Filed as internal issue #USD-10666

(This is an automated message. See here for more information.)