Fix schema error & in turn per-suite UI data provision

[sadielbartholomew]

These changes partially address #3216 (the table that is not rendered returns, populated with the suite's data, but the GraphQL error on 'state' is still there & needs further investigation).

This PR essentially reverts #3211 (bar one line), because whilst not X to test for a sequence being non-empty in a conditional is the Pythonic way advocated by PEP8, in this context the logic on field_ids needs to distinguish between an empty list & None (which that form does not do, as both are "falsy").

This is because field_ids = getattr(root, field_name, None) returns None as the default, & seems to be doing so for all the suites I have tried out to test this (as observed by adding in a print() function to check), whereas the query field argument default is an empty list (e.g. as here).

However, for the remaining line from the one commit of that PR, it is safe to use a not X construct for workflows as X because if workflows is None: is explicitly tested in the previous statement, which itself cannot return a None value:

https://github.com/kinow/cylc-flow/blob/67199ccc5c7abaa4f162f221e796adf5c5c83bc2/cylc/flow/network/schema.py#L699-L706

hence that line is safe & good.

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Off-template: Integration testing is important 😬!**
• No change log entry required (e.g. change is small or internal only).
• No documentation update required for this change.

[kinow]

Hi @sadielbartholomew !

We are here again! Déjà vu in cylc-flow haha, I remember breaking cylc-flow for the exact same reason, and you spotted it. Thanks, and thanks for the thorough explanation.

[kinow]

Off-template: Integration testing is important!**

+1 or even a simple unit testing just for some of these methods.

[sadielbartholomew]

It turns out that this PR fixes the missing table aspect of the corresponding Issue, but the GraphQL errors relating to 'state', raised as returned errors for queries & as a traceback in the terminal, remain there, so are not related to this. I've just edited the opening comment to this PR accordingly.

I will look into the cause of those errors tomorrow, if someone else doesn't diagnose the problem before then (feel free to!).