Fix silently ignoring file path in pvsystem.retrieve_sam when name is provided

[echedey-ls]

• Closes Using updated Sam datase  #2018
• I am familiar with the contributing guidelines
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

(EDIT: at first I did a crazy proposal of merging the two parameters, with deprecations and so on, but that's too much hassle for this issue)

Fixes ignoring path silently when name was provided.

I added a few more checks, and reworked the code. I think it is now clearer. And extended tests.

Docs links

• https://pvlib-python--2020.org.readthedocs.build/en/2020/reference/generated/pvlib.pvsystem.retrieve_sam.html

[mikofski]

I think this extra call is unnecessary, just use a try except or better yet let it raise key error:

try: 
    cvsdata = internal_dbs[name_lwr]
except KeyError as exc:
    raise exc  # or do what you want
else:  # only executes if no exception
    csvdata_path = Path(__file__).parent.joinpath(
                "data", cvsdata)

[echedey-ls]

That's a good idea. You've inspired me to avoid checking the existence of the file too.

[mikofski]

Not a blocker, but anyone consider using a constant INTERNAL_DBS at the top of the module instead of defining it on every call?

[echedey-ls]

I feel like something only used in a function is better placed near it, and I doubt the extra computation time does save significant time when there will be two calls at most in a script.

[mikofski]

In general beware of placing too many executions in try-except or else isolating exceptions can be more difficult. Best to limit one operation with known exceptions

[kandersolar]

LGTM. Thanks @echedey-ls!