Fixed a problem with the first drag update on a reorderable list.

[darrenaustin]

During the development of #81396 it was noticed the the drag calculations in the first frame of a reorderable list drag were off by the size of the dragged item. This is due to the implementation of the gap. During the drag the dragged item in the list is replaced by a zero sized item and all later items are just translated down by the gap size. This allows us to keep the order in the list while still being able to move the gap around based on the drag location. However, for the first frame of the drag the replacement of the zero sized box has not yet happened and any initial calculation of where the dragged item is will be off. During normal usage this isn't a problem because it is rare that you won't immediately have another drag event that will sort itself out. However in unit tests we only have a single drag event and it will be wrong.

This PR compensates for this issue and updates the tests so they are testing correct values.

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
• I signed the [CLA].
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
• All existing and new tests are passing.

[HansMuller]

Just set _dragStartTransitionComplete to true here, instead of using a post-frame callback?

[darrenaustin]

I thought about that, but the issue is that we don't know when this first update will occur. It could happen after the first frame, in which case we don't want to recompute the offset as it is already correct. Using this flag is just a way of making sure this is only recomputed if we are still before the first frame of the drag which is when we need to compensate for the dragged item that is still in the list.

[darrenaustin]

Another alternative I played with was to reset the flag from the build method of the dragged widget (when it was actually being replaced with the zero sized box). That seemed messier because it meant the child item widget was directly manipulating the state in the list (or I would need to expose a method). The post-frame callback seemed the most self contained.

[HansMuller]

I see, thanks for the detailed explanation!

[darrenaustin]

Thanks for the review.

[HansMuller]

LGTM