Keep ShaAttribute from halting startup when we can’t connect to Geo tracking database

What does this MR do?

Now we only check the column type (and therefor access the DB table) when we're not in production. In production, it behaves like any other attribute. But during development, the checks help ensure that we don't forget to set the column to :binary, etc.

And we no longer want to allow ShaAttribute to fail silently (we were returning nil in certain cases). If the system continued to run, it could cause the underlying binary data to be used without unpacking it, causing various queries to fail (see https://gitlab.com/charts/gitlab/issues/405)

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

A rogue database_geo.yml file made a Geo primary server think the Geo database was configured, which is only valid on a secondary. The server could not start. ShaAttribute will now fail cleanly.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• [-] Documentation created/updated
• API support added
• Tests added for this feature/bug
• Review
  • [-] Has been reviewed by UX
  • [-] Has been reviewed by Frontend
  • Has been reviewed by Backend
  • [-] Has been reviewed by Database
• [-] EE specific content should be in the top level /ee folder
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together
• [-] Internationalization required/considered
• [-] If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan
• End-to-end tests pass (package-qa manual pipeline job)

What are the relevant issue numbers?

Closes #5794 (closed)