Editor: Use Redux post types state for determining page feature support

[aduth]

Related: #3264, #3197

This pull request seeks to convert existing editor code using legacy lib/post-types-list to using Redux-based state and query components. This will become especially relevant with #3197, as otherwise the two approaches would make separate requests for post types from the REST API.

Implementation notes:

There is significant overlap between this pull request and #3264. In fact, this pull request cherry-picks 079f8b5, 19b11d0, and 776afa8 to incorporate <QueryPostTypes />. Whichever pull request is merged first, the other will be rebased to remove the redundant commits.

Testing instructions:

Verify that post type support continues to behave as expected. This can be dependent upon the current theme of the site, but typically posts support "all" features, whereas a page type will usually not support tags.

1. Navigate to the post editor or post editor
2. Select a site, if prompted
3. Note that sidebar options are reflective of the features supported by the current type
   • Feature detection includes: Tags, excerpt, geolocation, and comments
   • If you're unfamiliar with supported features for your theme, check against the /sites/%s/post-types endpoint for your site (example)

[timmyc]

could this return just be combined with the check for ! site above?

[timmyc]

Ah I see it is returning true - and that was the prior logic. Worst case I guess it could cause some flicker of a sidebar module.

[timmyc]

Looks good and tests out well. As noted above, the defaulting to true until the post-types are loaded does cause sidebar accordions to be shown at first, then hide once the store is loaded ( i.e. tags on pages when not supported ).

Since this is the current behavior - I think it is fine - and the other option would be to have these items "appear" after they redux state is loaded too - so we can't really get away from it I suppose.

LGTM

[aduth]

the other option would be to have these items "appear" after they redux state is loaded too - so we can't really get away from it I suppose.

Yeah, if I recall, the original decision was based around the fact that it's more likely that the post type will support a particular feature than it not, especially in the case of editing posts, which support all of the features we'd want to detect (unless the theme explicitly removes support).