Bad state after gpio input action stop

[dauriata]

With latest edge build 101.03, when triggering a gpio configured as action stop, the motion actually stops but a wrong position is reported ( updated to the target position )
Looks like we also end up in a program stop state but with the queue not flushed as a cycle start can finish the move
example moving from y0 to y200 and hitting stop in the middle of move :

As a side note, I was expected GPIO action stop and fast stop to behave like ! feedhold, but looking at the code I see that "fast stop" is not implemented and is like "stop". And "stop" does a program stop, not just like "!" feedhold. I think it would be more useful to have a hardware input button for just feedhold rather than feedhold followed by program stop. in my opinion program stop is more a function that would be done from the higher interface used to control the job.

[dauriata]

Just find out that this might be same bug as #479. Although this case is reproducible.

[lutorm]

I would also like to be able to trigger a feed hold with a GPIO. Being able to quickly trigger a feed hold with an external button is very useful if you see something going wrong.

[dauriata]

After digging again this issue after a while, I came to a working solution :
in edge-preview, I changed the _hold_input_handler in canonical_machine.cpp to :
cm_request_feedhold(FEEDHOLD_TYPE_ACTIONS, FEEDHOLD_EXIT_CYCLE);

FEEDHOLD_TYPE_ACTIONS allows feedhold to enter secondary planner p2 where gcode model is updated with current hold position instead of keeping target position.

FEEDHOLD_EXIT_CYCLE allows to resume cycle after entering feedhold

I believe this should be the default