Do not reset index when setting metadata

I just noticed a problem when setting epochs.metadata. When I create an Epochs object with the default reject_by_annotation=True behavior, bad epochs will be dropped. This includes rows from the metadata, but notice that the index still reflects the original epochs numbering.

For example, let's say we only have 6 epochs in total, and epochs 1 and 3 are bad and therefore dropped. This leaves epochs 0, 2, 4, and 5. However, certain operations like mne.channels.combine_channels() seem to set the metadata again (this is something that I fixed recently, previously the metadata attribute would be dropped completely). This means that the index is reset, and in our example would be 0, 1, 2, and 3, because https://github.com/mne-tools/mne-python/blob/main/mne/utils/mixin.py#L405 sets reset_index=True, which in turn is used in https://github.com/mne-tools/mne-python/blob/main/mne/utils/mixin.py#L369.

I don't know if this affects other functions in addition to mne.channels.combine_channels(), so I wanted to ask how you would recommend fixing this. I assume this behavior is not intended, right? I don't quite understand why the index is always reset, is it because we always want to make a copy? If so, there are two options: (1) we can use df.copy() (maybe even df.copy(deep=True)), and (2) we don't automatically copy and leave it to the user to do the right thing.

I kind of tend to prefer (2), because without looking at the source it is basically impossible to figure out that epochs.metadata = df creates a copy (and currently resets the index), which is probably not what the user wants (and expects).

Thoughts?

Read mne/utils/mixin.py around lines 369 and 405, then inspect how mne.channels.combine_channels() sets Epochs metadata. Reproduce the dropped-epoch example and determine the intended index behavior when metadata is assigned; done should preserve the relevant epoch numbering without breaking affected operations.