chore) Interpreter completion candidates are filtered out of the suggestion list

[okayhooni]

What is this PR for?

When an interpreter fills in the meta field of its completion candidates, none of them reach the suggestion list. Pressing Ctrl+. shows nothing at all, even though the backend answered with valid candidates.

completionSupportWithBackend decides what to keep by asking whether an item carries a meta value:

matches = matches.filter(function(item) {
  if (!_.isEmpty(item.meta)) {
    if (completionListLength !== 0) {
      return false;
    }
  }
  ...

The intent of ZEPPELIN-3001 (fe07e5a49) was to hide ace's own local/keyword suggestions once the interpreter has answered, and meta was used as the marker for "this candidate came from ace". That assumption does not hold — interpreters tag their own candidates with meta as well. SqlCompleter sends schema, table and column:

addCompletions(candidates, schemaCandidates, CompletionType.schema.name());
addCompletions(candidates, columnCandidates, CompletionType.column.name());
addCompletions(candidates, tableCandidates, CompletionType.table.name());

So the filter drops the backend's own suggestions along with ace's, and the list ends up empty.

The failure looks intermittent because the guard only lets anything through while completionListLength happens to be 0. That variable is declared per paragraph controller but is updated through $rootScope.$broadcast, and it is reset to undefined at the end of every filter pass — so whether anything shows depends on what the other paragraphs in the note last answered. Interpreters that leave meta empty are unaffected, which is why this went unnoticed for so long.

This PR marks the candidates built by remoteCompleter with an explicit fromBackend flag and filters on that instead of on meta. The original intent is preserved — ace's own suggestions are still hidden once the interpreter has answered — but the interpreter's candidates are always kept.

What type of PR is it?

Bug Fix

Todos

• - Mark interpreter-provided candidates with an explicit fromBackend flag
• - Filter on that flag instead of on meta

Related Jira issue (w/ regression) ?

• https://issues.apache.org/jira/browse/ZEPPELIN-3001

How should this be tested?

No automated test is included: the change lives in the AngularJS notebook UI (zeppelin-web/src/app/notebook/paragraph/paragraph.controller.js), which has no test harness covering ace's completion pipeline. Suggestions on how to cover it are welcome.

Manual steps, using any interpreter that tags meta — the JDBC family does:

1. Bind the jdbc interpreter to a database that has at least one schema with tables.
2. In a paragraph, type SELECT * FROM <schema>. and press Ctrl+..
   • Before: nothing appears. Occasionally the full ace list appears instead, depending on what the other paragraphs in the note last answered.
   • After: the schema's tables are listed with the table meta label, consistently on every press, and ace's local/keyword entries are hidden as ZEPPELIN-3001 intended.
3. Press Ctrl+. five or six times in a row and confirm the list is identical every time.
4. Repeat in a paragraph bound to an interpreter that leaves meta empty (for example python) and confirm its behavior is unchanged.

Before & After

Before	(empty suggestion list on a JDBC paragraph after Ctrl+.)
After	(the schema's tables listed with the table label)

Questions:

• Does the license files need to update? — No.
• Is there breaking changes for older versions? — No. The filter keeps its original behavior for
  interpreters that leave meta empty; only candidates that were previously dropped by mistake now
  appear.
• Does this needs documentation? — No.