Remove deprecated code for conda-build 24.7

[beeankha]

Description

This PR removes everything marked as deprecated in conda-build 24.7.x

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[codspeed-hq]

CodSpeed Performance Report

Merging #5333 will not alter performance

_{Comparing beeankha:remove-24.7.x-deprecations (35170f9) with main (d9edc57)}

Summary

✅ 3 untouched benchmarks

[kenodegard]

Confirmed this contains all of the removals, now that it's been double checked can we sort them alphabetically?

[beeankha]

Sounds good. I'll also try to make the news file easier to read like @jakirkham suggested

[kenodegard]

channel_data was previously postponed since the global variable (_channel_data) was still in use. What would it take for us to remove this global variable and instead only use a local variable?

[jakirkham]

Should we link out to a doc, summarize or streamline the list a bit?

An example of streamlining:

### Deprecations

* Remove `conda_build.conda_interface.*` component. (#5333):
  * `Completer`
  * ...

[beeankha]

That's a great idea!

[beeankha]

What do you think of this layout change/update, @kenodegard and @jakirkham ?

[kenodegard]

Personally I don't see much of a difference, it's still hard to read but that's simply a product of a lot of deprecations. We could truncate all of the conda_interface deprecations into Removed `conda_build.conda_interface`. but we'd loose the more detailed information about what users should be doing instead.

[jakirkham]

This seems reasonable

Was starting to wonder if we should capture this sort of thing in a linter tool (like ruff or similar). That would help us apply these changes throughout the different Conda* codebases

Maybe we would also be less reliant on having this in the release notes

[beeankha]

Hi @mbargull ! Wanted to ping you directly per your work in #5152 marking the channel_data constant for deprecation; does this update to _channel_data (removing the global variable and making this a local variable instead) look OK to you?

[mbargull]

No quite -- meaning, making it local doesn't take it far enough ;).
Sorry, I should've added a code comment there:
The idea was to remove it altogether since we populate it, but don't actually use it as of now.
Meaning, we should

1. remove everything from expanded_channels = ... (currently line 132) until _channel_data["defaults"] = ... (currently line 175), and
2. either omit the third return value or just return None instead.

As for point 2: I did a GitHub code search for orgs conda, conda-forge, regro, conda-incubator, bioconda, mamba-org and could not find any usage of get_build_index outside of conda-build itself, so removing the return value is probably fine (returning None instead is a more defensive variant which wouldn't break uses of index, ts, _ = get_build_index(...).

[kenodegard]

oooh! that makes much more sense!

yeah I'd just return an empty dict then so we don't modify the return structure/type

[mbargull]

This would, for one, of course remove unused code, but it would also avoid iterating over the index in expanded_channels = {rec.channel for rec in cached_index}.
On its own this doesn't yet change much really, since the index returned by conda.core.index.get_index/conda.core.index.fetch_index already has been iterated over (fetch_index does index.update((rec, rec) for rec in f.iter_records())).
But if/when we fix that initial iteration whilst addressing gh-5154, we can finally make use of deferred package record instantiation and shave off a good 30s and a whole lot of memory consumption.
Leaving the unused channel_data population in place would hinder that work, of course.

[mbargull]

yeah I'd just return an empty dict then so we don't modify the return structure/type

I thought about doing this too -- but I think a None would be a bit better since it would at least intentionally break uses of the then invalid channel_data (i.e., avoid silent errors in case this is really used somewhere).
N.B.: All uses in conda-build itself just ignore that return value anyway.

[mbargull]

Suggested change

	* `conda_build.index.channel_data`
	* `conda_build.index.channel_data`
	* `conda_build.index.get_build_index` return value for `channel_data` is now always `None`

or something along those lines maybe?

[beeankha]

Oh good call, I'll update the news file with this info!

The _channel_data variable issue has been removed/taken care of