Description

Currently, InputChips do not account for two things:

1. _layoutLabel now returns a Size that is properly constrained if there is a finite constraint.maxWidth.
2. The constraint calculations do not account for horizontal padding for the chip's shape when it has a finite constraint. This change incorporates it in layout calculations.

I also found that existing tests in chip_test.dart that utilize the _testConstrainedLabel have a brittle way of determining that a Chip and its avatar, label or delete icon is properly constrained by its parent, as it just checks to see if the label and chip's width and height are less than or equal to it's parent's width and height, since this does not account for:

1. whether or not they are constrained positionally,
2. whether or not having a combination of avatar, label and delete icon will cause overflow.

After some investigation, a cleaner fix that lays out the above will be complex, so this PR resolves the immediate issue of constraining the label and delete icon to a match its parent. I will file issues to track this need.

TODO:

• Create an issue regarding updating the tests and layout (Chip child widgets not laying out correctly if Chip's parent is constrained #31914)

Related Issues

Fixes #31790
Fixes #11523

Tests

• Regression test validating that all child widgets are constrained to the width of the Chip's parent widget

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.
• The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

• Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
• No, this is not a breaking change.