Implement catalog filter for KedroDataCatalog

[ElenaKhaustova]

Description

Implemented KedroDataCatalog.filter() to filter datasets by name and type.

Solves #3917

Reasoning: #3917 (comment)

Development notes

Implemented on top of #4448 <-- please review it first.

Developer Certificate of Origin

We need all contributions to comply with the Developer Certificate of Origin (DCO). All commits must be signed off by including a Signed-off-by line in the commit message. See our wiki for guidance.

If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass.

Checklist

• Read the contributing guidelines
• Signed off each commit with a Developer Certificate of Origin (DCO)
• Opened this PR as a 'Draft Pull Request' if it is work-in-progress
• Updated the documentation to reflect the code changes
• Added a description of this change in the RELEASE.md file
• Added tests to cover my changes
• Checked if this change will affect Kedro-Viz, and if so, communicated that with the Viz team

[astrojuanlu]

Thanks @ElenaKhaustova , that's what I imagined. In my view, given that our users aren't necessarily software engineers, our APIs shouldn't just be perfect partitions of the set of possible use cases, but allow for some convenience methods that, as @datajoely says, alleviate the burden a bit.

[merelcht]

I still feel like filter() is a more descriptive name and makes it more obvious that you can provide filter arguments. Whereas with list I wouldn't really expect to be able to add a regex argument.

So my vote would be: introduce filter now and remove list when we do 1.0.0

[ElenaKhaustova]

Thanks @ElenaKhaustova , that's what I imagined. In my view, given that our users aren't necessarily software engineers, our APIs shouldn't just be perfect partitions of the set of possible use cases, but allow for some convenience methods that, as @datajoely says, alleviate the burden a bit.

Could you please clarify whether you mean keeping the existing list implementation?

[ElenaKhaustova]

From the feedback and discussion here, we're going to:

1. Keep filter() name
2. Extend the current filter() implementation by accepting actual types

[merelcht]

LGTM 👍

I really like the addition of the by_type filter on top of the regex for type.

[astrojuanlu]

💯