[GOBBLIN-2153]added search attributes to Temporal workflows

[pratapaditya04]

Dear Gobblin maintainers,

Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!

JIRA

• My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"
  • https://issues.apache.org/jira/browse/GOBBLIN-2153

Description

• Here are some details about my PR, including screenshots (if applicable):
  Added flowGroup.flowName and user.to.proxy as SearchAttributes to filter Temporal Flows in the UI

Tests

• My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

• My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

[khandelwal-prateek]

It seems like the intention of this method is to convert the input map Map<String, List<?>> into a Map<String, Object> without transforming the list values into single objects. This method seems to be written for setSearchAttributes on ChildWorkflowOptions in AbstractNestingExecWorkflowImpl(which expects Map<String, Object>), we can simplify the implementation by directly using new HashMap<>(searchAttributes). This would achieve the same result more efficiently.

[pratapaditya04]

simplified the conversion, however have kept this function as we need validations as new HashMap<>(searchAttributes) throws NPE in case passed parameter is null

[Will-Lo]

What's the rationale for this try catch? Seems dangerous to ignore exceptions during processworkunits step, shouldn't we want it to fail loudly?

[pratapaditya04]

Help.loadJobState(workSpec, Help.loadFileSystem(workSpec)) throws a checked exception which needs to be catched, however have reduced the scope of the try catch block to this line

[Will-Lo]

If it throws an exception when loading the jobState (which I presume would lead to an empty jobState) we should just throw an ApplicationException in this scenario, so that we can push the Temporal framework to retry the workflow rather than progressing silently.

[pratapaditya04]

makes sense, addressed

[Will-Lo]

LGTM!