Expected behavior

Given an array of wp_query arguments with a numberposts value set, Timber::get_posts() should return that number of posts maximum, irrespective of the other query arguments.
Also: Timber::get_posts() should return the exact same posts as WordPress' get_posts() given the same arguments.

Actual behavior

Timber::get_posts() returns more than numberposts posts when using sticky posts. It looks like the sticky posts get added to the posts-array afterwards, increasing the number of posts by the number of sticky posts.
If ignore_sticky_posts=true is added to the query arguments, the correct number of posts is given.
Note that using WordPress' get_posts() does return the correct amount because ignore_sticky_posts=true is defined as default in get_posts() (wp-includes.php/post.php:1759).

Steps to reproduce behavior

• Create a query-arguments array with a numberposts value e.g.

$latestPostsArgs = array(
    'post_type' => 'post',
    'numberposts' => 10,
    'post_status' => 'publish'
);

• Make sure you have more than numberposts posts of said post types
• Mark a few of these posts as sticky post
• Fetch the posts e.g.
  $posts = Timber::get_posts($latestPostsArgs);
• Note that the number of posts returned is greater than the numberposts value because of the sticky posts that get added:
  echo count($posts); //prints 13, in my case
• Also note that when using WordPress' get_posts() using the same query arguments, the correct number of posts is returned:
  $wpPosts = get_posts(latestPostsArgs);
echo count($wpPosts); //prints 10
• Also note that if we add 'ignore_sticky_posts'=>true to the query arguments, the correct number of posts is returned

What version of WordPress, PHP and Timber are you using?

WordPress 4.9.8, PHP 7.2.8, Timber 1.8.1

How did you install Timber? (for example, from GitHub, Composer/Packagist, WP.org?)

Composer/Packagist

Proposed fix

Because WordPress' get_posts() sets ignore_sticky_posts=true as default, I think the same should be applied to Timber::get_posts(). The best way to do so may be by adding another "fix"-action in QueryIterator.php's constructor.
I will add a PR in a few moments with a proposed fix.