Search: Filter the search results based on block types

[ryelle]

If the allowed_blocks meta filter is set, we should also pass that through to the ElasticSearch filters. Currently, if you make a request via the API with the allowed_blocks parameter, it will correctly return only patterns with those blocks. If you add a search term, it skips the filtering and returns all matching patterns. Searches should also return only patterns with matching blocks.

I've already added the wpop_contains_block_types meta to the synced data in 8ac046d. This PR adds the filter to the ES query so that it should do the same regex matching to return only patterns with a subset of blocks in the given allowed_blocks.

See #540 (comment). Fixes #547.

How to test the changes in this Pull Request:

No idea 😓 this is my best guess based on the ES docs. @iandunn you've worked on the search code here before, how can I test this either locally or on a sandbox?

Note - search queries without allowed_blocks should still work, as the pattern directory itself doesn't supply allowed_blocks.

[iandunn]

It's been awhile, but it looks like uploading the code to a sandbox is all that's needed to affect the output of the API response (albeit not in the desired way). I don't think it's possible to test locally, since the server needs to authenticate as w.org to get access to the custom ES index. Adding a PHPUnit test in the api.w.org repo is another way to test, and I'd recommend that too for all the normal reasons.

I'd probably start by using Sense to test the raw ES query; I found that helpful before moving it to PHP code, since I ran into a lot of problems just getting the query right. There's info on accessing Sense in the A8C FG. I think you can get the raw query from Automattic\Jetpack\Search\Classic_Search\search(). The #elasticsearch channel on A8C is a good place to get input from folks who know it well, but I'm also happy to help where I can.