XYFocus should skip effectively disabled controls

[IanRawley]

What does the pull request do?

Changes XYFocus.IsValidCandidate to check IsEffectivelyEnabled and IsEffectivelyVisible instead of IsEnabled and IsVisible

What is the current behavior?

When a control is effectively disabled (for example a Button bound to a Command with CanExecute = false) XYFocus will still consider it a valid candidate. If such a control ends up being the best candidate it turns into a focus roadblock as it cannot actually be focused.

What is the updated/expected behavior with this PR?

Controls that are disabled by means other than changing IsEnabled are skipped for XYFocus, preventing them from blocking navigation.

How was the solution implemented (if it's not obvious)?

XYFocus.IsValidCandidate() was changed to check IsEffectivelyEnabled and IsEffectivelyVisible instead of IsEnabled and IsVisible

Checklist

• [✓ ] Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Behavioural changes if effectively disabled controls were being used as navigation blockers.

Obsoletions / Deprecations

None

Fixed issues

Fixes #20239

Notes

I am a little concerned by IsValidFocusSubtree.

// We don't need to check for effective values, as we've already checked parents of this subtree on previous steps. 
return candidate.IsVisible &&
       candidate.IsEnabled;

It says effective values are checked, but I can't see where (other than the changes I have just made). This does seem to be related to focus engagement though, which as far as I know isn't implemented.

[avaloniaui-bot]

You can test this PR using the following package version. 12.0.999-cibuild0060679-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]