MudChipSet: use SelectionMode instead of MultiSelect and Mandatory

[henon]

Description

Followup to the ChipSet rework in #4342

Replaced the dual parameters MultiSelection and Mandatory with SelectionMode which was originally introduced for MudToggleGroup. MudTreeView now also uses the new SelectionMode and MudList is also gonna use it when we implement multi-selection for it. This is an effort to unify selection features in the library.

Note: MudSelect, MudTable and MudDataGrid and some others still use MultiSelect="true". We might also change them, but I doubt it is gonna be possible to do this in v7.

Warning

MudChipSet: Replace the dual parameters MultiSelection and Mandatory with SelectionMode. MultiSelection="true" corresponds to SelectionMode.MultiSelection. For the default single-selection of the old chip set use SelectionMode.ToggleSelection and Mandatory="true" corresponds to SelectionMode.SingleSelection.
Due to the unification of selection features over all components the default selection mode of MudChipSet has changed. Prior to v7 chips could be selected off by default. In v7 the default is SelectionMode.SingleSelection (like for all other components that support parameter SelectionMode) which does not allow to de-select chips by clicking again. Set to SelectionMode.ToggleSelection for that. #8722

MultiSelection	Mandatory	SelectionMode
true	*	SelectionMode.MultiSelection
false	true	SelectionMode.SingleSelection
false	false	SelectionMode.ToggleSelection

How Has This Been Tested?

unit

Type of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (fix or improvement to the website or code docs)

Checklist

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[henon]

The collection comparer can only be added to _selectedValues state once #8661 is merged.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.14%. Comparing base (28bc599) to head (6c6bd42).
Report is 75 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #8722      +/-   ##
==========================================
+ Coverage   89.82%   90.14%   +0.31%     
==========================================
  Files         412      419       +7     
  Lines       11878    12181     +303     
  Branches     2364     2396      +32     
==========================================
+ Hits        10670    10981     +311     
+ Misses        681      664      -17     
- Partials      527      536       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[henon]

Added to v7.0.0 Migration Guide #8447

[henon]

This one is done

[ScarletKuro]

Tests failed, I wonder if it's related

[henon]

Tests failed, I wonder if it's related

Yes. My implementation completely broke down, not sure why, but seeing how unstable it was I had to overhaul it again. I had to do it like in TreeView, that in single selection mode SelectedValues is ignored and in multi selection SelectedValue is ignored.

[ScarletKuro]

Yes. My implementation completely broke down, not sure why, but seeing how unstable it was I had to overhaul it again. I had to do it like in TreeView, that in single selection mode SelectedValues is ignored and in multi selection SelectedValue is ignored.

Yea, it seems just adding comparer to SelectedValues break everything and the implementation requires UpdateSelectionAsync invoke when it shouldn't, but I see that my code and the CollectionComparer works correctly when you compare the x, y

[ScarletKuro]

Btw, not related question, but why such complicated GetHasCode?
Wouldn't this just work?

public int GetHashCode(IReadOnlyCollection<T> obj)
{
	var hasher = new HashCode();
	foreach (var item in obj)
	{
		if (item is not null)
		{
			hasher.Add(_comparer.GetHashCode(item));
		}
	}

	return hasher.ToHashCode();
}

Why does it require Distinct and an OrderBy (don't we care only about the sum of the items)? Shouldn't the items be unique anyway if the derivering type of IReadOnlyCollection is a HashSet?
Upd: looking at your test I see why you use Distinct

[henon]

As I understand it hashing algorithms are not commutative. So if you hash [1, 2, 3] and [3,2,1] you'll get different results.

[henon]

And we don't know if the user supplies a hash set. IReadOnlyCollection can be anything, such as Array, List, etc