EMSUSD-490 Fixes outerliner not refreshing when performing a UsdUndoVisibleCommand

[AramAzhari-adsk]

When undoing a visibility command, UsdNotice::ObjectsChanged does not produce a path for Info Change but still generates a path for Re-sync Change which has the Visibility token. The special case is added to refresh when in the latter path.

[AramAzhari-adsk]

It seems that when:

1- Making a prim invisible the following notifications are sent:
    AttributeChangeType::ValueAdded
    AttributeChangeType::ValueChanged

2- When setting the visibility back to "Inherited" / "Visible", only the following is sent which makes sense as the attribute already exists:
    AttributeChangeType::ValueChanged

3- When Undoing after manually making an item invisible, only the following notification is sent as the attribute will now be inheriting data:
    AttributeChangeType::ValueRemoved

This is checked here:

maya-usd/lib/usdUfe/ufe/StagesSubject.cpp

Lines 142 to 167 in ce7fc17

	switch (changeType) {
	case AttributeChangeType::kValueChanged: {
	notifyWithoutExceptions<Ufe::Attributes>(
	Ufe::AttributeValueChanged(ufePath, changedToken.GetString()));
	if (UsdUfe::UsdCamera::isCameraToken(changedToken)) {
	notifyWithoutExceptions<Ufe::Camera>(ufePath);
	}
	} break;
	case AttributeChangeType::kAdded: {
	if (UsdUfe::InSetAttribute::inSetAttribute()) {
	notifyWithoutExceptions<Ufe::Attributes>(
	Ufe::AttributeValueChanged(ufePath, changedToken.GetString()));
	if (UsdUfe::UsdCamera::isCameraToken(changedToken)) {
	notifyWithoutExceptions<Ufe::Camera>(ufePath);
	}
	} else {
	notifyWithoutExceptions<Ufe::Attributes>(
	Ufe::AttributeAdded(ufePath, changedToken.GetString()));
	}
	} break;
	case AttributeChangeType::kRemoved: {
	notifyWithoutExceptions<Ufe::Attributes>(
	Ufe::AttributeRemoved(ufePath, changedToken.GetString()));
	} break;

The bug is for #3. @seando-adsk Should we move the fix inside the     AttributeChangeType::ValueRemoved ?
I noticed there is a special case for the Camera in some of the AttributeChangeTypes

[seando-adsk]

I'm not sure the order matters, but I wonder if sending this extra visibilityChanged should come after the processAttributeChanges() just below. This would then match the order in the ChangedInfoOnlyPaths() loop.

[AramAzhari-adsk]

@seando-adsk I actually had to move it as per this finding since having it in at line 398 caused duplicate notifications to be sent which failed the visibility test.

[AramAzhari-adsk]

One test on one platform did not pass which is a known random occurrence:
testVP2RenderDelegateUsdSkel