Update tab counters on filter change

[flash1293]

Summary

Fixes #19524 by updating the tab counters if the filter is changed.

@timroes The fix is in the angular code, so a complete EUI-ification of the edit index pattern section would fix this problem. If we get this in before 7.1 feature freeze, we don't need this PR.

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

[flash1293]

Related: I noticed a small error in kbn-ui - the selected tab doesn't stand out anymore (due to a change during dark mode integration). Is this worth fixing?
Old:

New:

[elasticmachine]

💚 Build Succeeded

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

[timroes]

@flash1293 I was wondering (maybe you know the code now to estimate this), if it's worth when filtering down, actually not showing the plain number of now found fields, but instead something like Fields (9/85) or Fields (9 of 85)?

[flash1293]

@timroes This is easy to add to the current state. I also forgot to filter the counts for the source filters, I will add this to the PR.

[flash1293]

This doesn't respect the language filter in the "Scripted fields" tab - does this even work in the newer versions? Can this dropdown be removed completely?

The control flow is a little awkward, because the individual tables do their own filtering (we basically filter twice, once in angular for the tabs, once in react for the actual table). But if we fix this now we might as well EUI-ify the whole thing which is a little more effort.

[flash1293]

I looked into the code and in
src/legacy/ui/public/scripting_languages/index.js and src/legacy/core_plugins/kibana/server/routes/api/scripts/register_languages.js it is hardcoded that there will only be painless. Is there a reason why the code around this is still kept in place?

[elasticmachine]

💚 Build Succeeded

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

[timroes]

You can still create a scripted field with the language expression for numeric fields, having some (I think) Lucene calculation language.

[elasticmachine]

Pinging @elastic/kibana-app

[flash1293]

@timroes Not since late 2017 (at least according to #14310 ) - the code also looks like this is the case. Maybe I overlook something

[timroes]

Tested on Chrome Linux. Seems to work fine. Code LGTM.
I would leave the code for multiple languages for now in there. Maybe if we refactor that part we can discuss throwing it out, but I see not current need for that (and I anyway wouldn't do it in this PR :D)