Follow-up: Fix group level work item count caching

MR: Fix group work item count caching (!209505 - merged)

The following discussion from !206305 (merged) should be addressed:

• @mcelicalderonG started a discussion: (+1 comment)

  @mdangelo6 quick question. Is there a reason why we shouldn't store this result in the cache like we do for project level counts? Might even make more sense for heavier queries like this one that will go through the entire hierarchy, right?

Currently, the cache_issues_count? method returns false for the group issues list, so the counts are never cached. This is due to the params_include_filters? returning true, since we also pass in include_ancestors and exclude_group_work_items into the query.

We should consider adding these to the non_filtering_params array so the counts can be cached for the group issues list.

We'll also need to handle the case where type filtering is applied on the list. Right now we consider issue_types to be a non-filtering param, since this is always passed for the epics list, however this can be a filter param for the group issues list