Fix Release features tables cross-joining `ci_builds` -> Environments dashboards Environment#last_visible_pipeline last_visible_deployable last_deployable

Summary

Code used in environments dashboard pages is causing problems with moving ci_* tables to a new database (ie. the current groupsharding decomposition efforts).

Technical details

The following has_one relations from https://gitlab.com/gitlab-org/gitlab/-/blob/ee956e0dfc4f2e37f4f37fc63b50c3f50376195a/app/models/environment.rb#L30 do cross-joins between ci_* and non ci_* tables:

has_one :last_deployable, through: :last_deployment, source: 'deployable', source_type: 'CommitStatus'
has_one :last_visible_deployable, through: :last_visible_deployment, source: 'deployable', source_type: 'CommitStatus'
has_one :last_visible_pipeline, through: :last_visible_deployable, source: 'pipeline'

These methods are used in a few places but the main tricky part to solve is using them as preload in Dashboard::Environments::ListService.

The last_visible_pipeline chains together all the others.

Possible solutions

I started testing different approaches at !67834 (closed) but it turned out to be a bit trickier than expected so we want to distribute this work to relevant team so that they can

1. Similar to !66709 (merged) we can add disable_joins to these but my initial testing of this did not seem to work out of the box due to the interesting way these construct results using scopes and distinct. We could look into whether this is a bug in disable_joins that's easily fixed but I fear there may be technically something strange about these has_one relations being used in a way this feature was not intended
2. In !67834 (closed) I also tried extracting all these has_one as a method but I realised later that this won't work with the preload. But it could be possible to write the preloading logic more directly for these relations and still avoid using has_one for this.

You can read more about typical solutions to these types of join problems at https://docs.gitlab.com/ee/development/database/multiple_databases.html#removing-joins-between-ci_-and-non-ci_-tables . It may turn out there is a simpler way to refactor this code that doesn't rely on these has_one or joins.