[DO NOT MERGE] Batch connect erb fix

[ericfranz]

Fixes #417

When building navigation menu, we previously rendered the form.yml.erb
files to get the title and description.

This change prevents rendering the erb to build the navigation menu by default.

For "subapps" i.e. desktop configs, you can add a manifest per config with the same
name as the form.yml, but with .manifest.yml as the extension. Otherwise the titleized
form of the filename will be used.

For previous functionality set OOD_RENDER_BATCH_CONNECT_ERB_FOR_NAV=1

I copied an integration test that was already testing the interactive apps menu built because it was easy. That test can probably be simplified and setup duplication moved to a helper method - or even this set of tests moved to a separate test file - that might make things clearer.

[ericfranz]

I need to fix something. This method still does erb rendering:

     # Description for the batch connect app
    # @return [String] description of app
    def description
      form_config.fetch(:description, default_description)
end

In fact, it would be proper or even ideal to have a separate BatchConnect::App object that does no erb rendering ever, just to ensure this never occurs and get rid of some logic at the same time.

[ericfranz]

1. Add a test to verify the erb rendering code never gets called
2. Another problem is without erb rendering OodApp#cluster_id would inevitably would not be defined (and thus dependency on a cluster that the user has no access to would not prevent that app from appearing in the menu).

[ericfranz]

The last commit I made to the PR is problematic and doesn't have tests. I mean it probably works, but other edge case bugs are introduced. For example:

• if you specify cluster id in manifest and in form.yml - which is the only way to
• if you forget to specify cluster id in form.yml but do so in manifest - does it still work? if not, the valid? method will now return true

These edge cases aren't worth fixing though IMHO. We should not have "subapps" to begin with which is what introduces the complexity here.

Proper tests would verify a normal batch connect app (Jupyter) and a sub app (some Desktop) would both be "uauthorized" if they submitted to "ruby" cluster and you werent part of the required group, for example (i.e. mock job_allow? to return false on the specified adapter).