Return empty string if no geneset version in database

[ao508]

Signed-off-by: Angelica Ochoa 15623749+ao508@users.noreply.github.com

Fix # (see https://help.github.com/en/articles/closing-issues-using-keywords)

Describe changes proposed in this pull request:

• Resolves exception thrown in validateData.py when None is returned when fetching portal info from a URL.

Traceback (most recent call last):
  File "/data/portal-cron/git-repos/cbioportal/core/src/main/scripts/importer/validateData.py", line 5465, in <module>
    exit_status = main_validate(parsed_args)
  File "/data/portal-cron/git-repos/cbioportal/core/src/main/scripts/importer/validateData.py", line 5434, in main_validate
    portal_instance = load_portal_info(server_url, logger)
  File "/data/portal-cron/git-repos/cbioportal/core/src/main/scripts/importer/validateData.py", line 5050, in load_portal_info
    parsed_json = request_from_portal_api(path, api_name, logger)
  File "/data/portal-cron/git-repos/cbioportal/core/src/main/scripts/importer/validateData.py", line 4922, in request_from_portal_api
    return response.json()
  File "/data/tools/python3.4.10/lib/python3.4/site-packages/requests/models.py", line 897, in json
    return complexjson.loads(self.text, **kwargs)
  File "/data/tools/python3.4.10/lib/python3.4/json/__init__.py", line 318, in loads
    return _default_decoder.decode(s)
  File "/data/tools/python3.4.10/lib/python3.4/json/decoder.py", line 343, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/data/tools/python3.4.10/lib/python3.4/json/decoder.py", line 361, in raw_decode
    raise ValueError(errmsg("Expecting value", s, err.value)) from None
ValueError: Expecting value: line 1 column 1 (char 0)

None type can't be parsed as JSON - the endpoint will now return an empty string instead.

Checks

• Runs on heroku
• Has tests or has a separate issue that describes the types of test that should be created. If no test is included it should explicitly be mentioned in the PR why there is no test.
• The commit log is comprehensible. It follows 7 rules of great commit messages. For most PRs a single commit should suffice, in some cases multiple topical commits can be useful. During review it is ok to see tiny commits (e.g. Fix reviewer comments), but right before the code gets merged to master or rc branch, any such commits should be squashed since they are useless to the other developers. Definitely avoid merge commits, use rebase instead.
• Is this PR adding logic based on one or more clinical attributes? If yes, please make sure validation for this attribute is also present in the data validation / data loading layers (in backend repo) and documented in File-Formats Clinical data section!

Any screenshots or GIFs?

If this is a new visual feature please add a before/after screenshot or gif
here with e.g. Giphy CAPTURE or Peek

Notify reviewers

Read our Pull request merging
policy. It can help to figure out who worked on the
file before you. Please use git blame <filename> to determine that
and notify them either through slack or by assigning them as a reviewer on the PR