In the situation described in
https://bugzilla.gnome.org/show_bug.cgi?id=795397,

downstream_caps consists of two structures, the first with
the preferred rate, if at all possible (44100), the second
containing the full range of allowed rates, as audioresample
correctly tries to negotiate passthrough caps.

As audioaggregator cannot perform rate conversion, it wants
to return a fixated rate in its getcaps implementation,
however it previously directly used the first structure in
the caps allowed downstream, without taking the filter into
consideration, to determine the rate to fixate to.

With this, we first intersect our downstream caps with the
filter, in order not to fixate to an unsupported rate.