bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs

[Philipp]

> Am 18.03.2021 um 15:01 schrieb Stefan Monnier <monnier@iro.umontreal.ca>:
> 
>>> No.  And I'd hope the problem can be avoided in all cases.
>>> I guess we could try and make it more "official" by imposing some kind of 
>>> "cut"
>>> such that after passing a `&define` we can't backtrack.
>> From looking at the code, would it be possible to achieve this by setting
>> edebug-gate to non-nil in the right places?
>> If so, then this seems to be only a matter of finding the right places ;-)
> 
> It's possible, but:
> - I don't understand enough the way backtracking works in Edebug to know
>  what `edebug-gate` does, really.

It looks like you can set edebug-gate to t in edebug--match-&-spec-op (the 
&define branch).  That should have the same effect as a [gate ...] construct 
around each &define form.

> - The old spec of `cl-flet` would be broken by such a change, so if we
>  want to make such a change, we'd probably want to arrange so that it
>  emits a clear warning.

Where?  When setting the debug specification (byte-run--set-debug), or in some 
other place?

> 
> I'm not sure it's worth the trouble: the pain seems higher than the gain.
> 

This bug is rather nasty when it's hit (it took me quite a while to debug/hunt 
down), so I think it would be reasonable to prevent.  We already disable 
backtracking for literal symbols, and I think forms that require multiple 
&define forms with backtracking should be exceedingly rare and can be rewritten 
as you did with cl-flet.