[Logs UI] Fix inaccuracy when jumping to a faraway time target

[Zacqary]

Summary

Fixes #39944

This fixes a bug that would cause changing the timestamp in the Logs UI to a timestamp outside the currently loaded range of logs to end up landing you on a very far off place than you actually clicked on. It would also sometimes send you to a very far off timestamp when initially loading the page with a specific timestamp in the URL.

After a lot of investigation, I was able to track the issue down to the getVisibleChildren call in VerticalScrollPanel's getSnapshotBeforeUpdate. When the panel is mounted, it's supposed to behave like so:

1. The user scrolls through the panel
2. New log entries load when the user reaches the edge of loaded logs, prompting the component's children to change
3. The component reports the new visible log entries to update the displayed time window in the log minimap and the toolbar

This works fine. The problem is that when the component is first mounted, its children, height, and width properties aren't finalized yet for another animation frame or so. So what happened was:

1. The application loads log data for a large chunk of time before and after the target timestamp, with the intention of displaying the target in the very center of the log stream
2. The component mounts and tries to jump to its target log entry. Since its height is 0, it doesn't actually scroll anywhere.
3. The surrounding AutoSizer figures out how tall to make the component and updates it. The children also get re-rendered because they depend on some data being computed from WithColumnWidths
4. The component updates again in response to the height and children changes, and calls getVisibleChildren. Because it hadn't actually scrolled down at all when its height was 0, the visible children are actually the beginning of available data
5. The component reports that the beginning of the data (rather than the center) is visible, and the toolbar and log minimap change to reflect this.

This created a very annoying situation where the user might:

1. Click on 3:00pm in the toolbar or log minimap
2. Wait for the application to load logs from 12:00pm till 6:00pm
3. Watch the logs for 12:00pm appear at the top of the logs stream and see the timestamp in the toolbar and the highlighted window in the log minimap both jump from 3:00pm to 12:00pm

This PR should prevent this from happening anymore.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• [ ] Documentation was added for features that require explanation or tutorials
• [ ] Unit or functional tests were updated or added to match the most common scenarios
• [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/infra-logs-ui

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[weltenwort]

This is great! Jumping around in the logs feels so much more accurate now. And extra credits for the explanation. The awesomeness of this fix is inversely proportional to its line count 😉