Unnecessary encoding of `def_span` query in metadata

[oli-obk]

There were some perf regressions due #80191 can be seen here

Originally posted by @rylev in #80919 (comment)

We need to find out which kind (as what variant of def_kind) of things now get their def_span encoded and stop doing that.

Bonus points for also checking which additional DefKinds we can exclude to minimize the amount of spans that are put into metadata (someone remind me why we need spans in metadata at all?)

[Aaron1011]

someone remind me why we need spans in metadata at all?

I believe the main use is for diagnostics. For macro_rules! macros, we need to preserve spans of tokens for correctness (this is especially important when a macro_rules! macro is generated by another macro).

[oli-obk]

ok... so DefKind::Macro(_) may be the only real user of this, though errors pointing into locally built crates may be improved by it.

I guess let's try to get the previous status quo reestablished first, not emitting Spans for things that don't need them.

[cjgillot]

someone remind me why we need spans in metadata at all?

I am wondering the same thing for ident_span.
Those are used for one diagnostic, and to create the Ident for imported items.
It's not clear to me whether the latter uses are semantic or diagnostic.

[jyn514]

Rustdoc also uses def_span:

rust/src/librustdoc/clean/types.rs

Lines 147 to 148 in b122908

	let source = def_id.as_local().map_or_else(
	|| cx.tcx.def_span(def_id),

[tmiasko]

In contrast, there is a report of a missing def_span in #81540 (using rustc before changes in question landed).

[oli-obk]

Hmm... so this perf regression may in fact be due to a bugfix