Wip fix gitaly client storage settings gitaly address method

What does this MR do?

The Gitlab::GitalyClient::StorageSettings#gitaly_address currently fails, because the GitLab configurations in both the production and staging environments defines the gitaly address entry for each node's storage setting using a string key, but the method actually tries to fetch the value based on a symbolic key.

Interestingly enough, the config/gitlab.yml.example file uses a symbolic key.

This implies that there was a mistake made when the gitaly address for each node's storage settings were added. Both fortunately and not, the Gitlab::GitalyClient::StorageSettings#gitaly_address is actually never invoked anywhere in the codebase, and so this method could be considered to be effectively "dead code". However, it is certainly convenient to be able to have access to the gitaly_address in side-car tooling, and in the rails console.

This fix simply introduces a secondary fetch using a string key, as a fall-back for the case in which a string key appears in the storage settings of gitlab/config.rb.

Screenshots

No relevant screenshots -- not a UI change.

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• [-] Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Performance and Testing

• What risks does this change pose? How might it affect the quality/performance of the product?

This change poses little risk, especially considering that the altered code lines are not explicitly invoked by the program.

• What additional test coverage or changes to tests will be needed?

Added four additional spec tests to cover the current failure mode and additional behavioral expectations for the new functionality.

• Will it require cross-browser testing?

No -- not a UI change.

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team