Include name of export in index already exists notice

[antiguru]

Include the name of the exported index in the index already exists notice.

Motivation

• This PR fixes a previously unreported bug: https://materializeinc.slack.com/archives/CU7ELJ6E9/p1716231408100059

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[teskje]

Seems fine, but I have some trouble understanding why this is needed. If the notice is emitted in response to a CREATE INDEX command, it should be clear what index it is about. Is it also emitted in other cases?

[teskje]

Naming nit: Maybe this would be clearer with old_index_id/new_index_id or existing_index_id/new_index_id, instead of index_id/exported_index_id?

[antiguru]

I agree, but that's the names that are used elsewhere, so I didn't want to touch it!

[aalexandrov]

IIRC I we didn't add this originally because we were thinking that when the notice is initially generated as part of (1) CREATE INDEX or (2) EXPLAIN CREATE INDEX we call and IndexAlreadyExists::fmt_message(...) with a humanizer: &dyn ExprHumanizer that wraps a version of the ConnCatalog that doesn't have an entry for the new index.

However, I now remembered that for (2) we use a composite ExprHumanizerExt struct so this won't be an issue

materialize/src/adapter/src/coord/sequencer/inner/create_index.rs

Lines 551 to 565 in 5553085

	let expr_humanizer = {
	let on_entry = self.catalog.get_entry(&index.on);
	let full_name = self.catalog.resolve_full_name(&name, on_entry.conn_id());
	let on_desc = on_entry
	.desc(&full_name)
	.expect("can only create indexes on items with a valid description");
	let transient_items = btreemap! {
	exported_index_id => TransientItem::new(
	Some(full_name.into_parts()),
	Some(on_desc.iter_names().map(|c| c.to_string()).collect()),
	)
	};
	ExprHumanizerExt::new(transient_items, &session_catalog)
	};

I'm curious to see if this works for (1) out of the box, though. The rewritten version of test/sqllogictest/transform/notice/index_already_exists.slt should tell us more once it is included in the PR.

[antiguru]

If the notice is emitted in response to a CREATE INDEX command, it should be clear what index it is about. Is it also emitted in other cases?

I think you can type CREATE INDEX a ...; CREATE INDEX b ...;, and you'd lose the connection to which notice corresponds to which command, but I'm totally making this up, too!