Better view analysis

[EdwardLarson]

One sentence summary of this PR (This should go in the CHANGELOG!)
Choose Analyzer components which output the entirety of a view, rather than piece by piece, which would choose the wrong Analyzer sometimes.

Link to Related Issue(s)
ResourceViews are composed of multiple attributes types, and when running something like view_as OFRAK would previously make a request for each of those attributes types. With limited visibility into what the user actually wants, the job service would sometimes end up choosing Analyzers which do output one or more of the requested attributes but actually require the analysis of the other attributes, resulting in a deadlock.

Please describe the changes in your request.

• Auto-analyze attributes requests now can take multiple attributes types at once (and view_as uses this)
• The component filter for analyzer output looks for analyzers which output all of the requested attributes (and possibly other attributes as well), instead of any analyzers which output one or more of the requested attributes
• When auto-analyzing attributes, the job service first looks for an Analyzer outputting all of the requested attributes, and if such an Analyzer is not found, falls back to looking for Analyzers for each requested attribute individually (the previous behavior)

Anyone you think should look at this, specifically?
@rbs-jacob

[rbs-jacob]

I'm a little confused about whether this reliably solves the problem based on this last bullet:

• When auto-analyzing attributes, the job service first looks for an Analyzer outputting all of the requested attributes, and if such an Analyzer is not found, falls back to looking for Analyzers for each requested attribute individually (the previous behavior)

This makes it sound like there is still a risk of deadlock in certain circumstances?

[EdwardLarson]

This makes it sound like there is still a risk of deadlock in certain circumstances?

That's correct. The true solution to the root cause would be pretty complicated. The approach I have in mind is to flesh out the job context to include a "stack" of the components or at least analyzers being run, and raise an error when the same analyzer appears twice in the stack. However that would take me a couple days at least to do, this took me an hour or so.

And besides this does solve a real problem: The wrong analyzer was being chosen in a test that was deadlocking. The job service was choosing the ComplexBlockSymbolAnalyzer for one of the attributes in a ComplexBlock view, and using the ComplexBlockAnalyzer for other attributes. Since the former indirectly calls the latter, the set of analysis tasks was deadlocking.

[rbs-jacob]

Thanks for the clarification!

[rbs-jacob]

Two very small changes, and this should be good to go!