bug#73473: 31.0.50; Minibuffer completions include nonsense prefix candidates

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> I've noticed that my completions have slowed down A LOT on recent Emacs
>> builds, it turns out nonsense completion candidates (which I am calling
>> "prefix candidates") are being included as... completion candidates.
[...]
>> To reproduce, using `emacs -Q` of course:
>>
>> 1. Open Emacs.
>> 2. C-h o foo TAB
[...]
>> If I do the same on the currently released Emacs or another (older)
>> build of Emacs (30.0.50) there are 79 (not 80) completion candidates and
>> `footnote-` is not listed as one.

This was done on-purpose: the `footnote-` prefix is included as a "stand
in" for the not-yet-loaded definitions of `footnote.el`.  The idea is
that if you're looking for, say, `PREFIX-SUFFIX` in package PREFIX you
can get there by doing

    C-h o PREF TAB

which completes to `PREFIX-`, and then

    SUF TAB

(which now works because `PREFIX.el` was loaded under the hood).

AFAICT, there is a performance bug here in that just doing the
`C-h o PREF TAB` which completes to `PREFIX-` already loads `PREFIX.el`
which is a bit over-enthusiatic (I intended it to load `PREFIX.el`
only when you hit TAB while you already have `PREFIX-` in your
minibuffer).

>> This seems to be occurring for almost every unique prefix possible, 
>> compounding as time goes on. So later on `f-` is listed as a completion 
>> candidate, then also `go-` and so on. These are not valid completion 
>> candidates. `footnote-` is not a symbol. Over time the huge increase in 
>> completion candidate volume (and perhaps what is causing this behind the 
>> scenes) results in such a slowdown that I can visibly see Emacs crawl to 
>> 1 FPS when I type in minibuffer completion, when the exact same init.el 
>> on said older 30.0.50 is faster.

It's probably not directly linked to the number of symbols defined, but
rather to side-effects introduced by some of the packages that were
loaded (which I'd argue are probably themselves (performance) bugs in
those packages).


        Stefan