Procedures: fix scheduling

[Centril]

Description of Changes

Reworks how SchedulerActor::handle_queued works so that it first determines the parameters of the call to a reducer or the parameters of the call to the procedure. This also enables the removal of the special case call_scheduled_reducer.

Fixes #3645.

API and ABI breaking changes

None

Expected complexity level and risk

2

Testing

A test schedule_procedure is added.

[gefjon]

This all looks reasonable to me, but I'm not super familiar with our scheduling code. I'd like to get @Shubham8287 's review before merging, if possible.

[gefjon]

It occurs to me - for a procedure, you have to delete the schedule row before invoking, not after. If execution aborts (host crash or w/e) midway through a scheduled procedure, it's not correct to retry that procedure on restart the way it is for a scheduled reducer, so you need the row to be gone by the time the procedure performs any observable side effect. I think that this means that we should:

• When the schedule fires, open a mut tx.
• Within that TX, determine whether the function is a reducer or a procedure.
• If it's a reducer, use the mut TX to execute the reducer, as normal.
• If it's a procedure, delete the row, commit the TX, then invoke the procedure without a TX open.

There's some additional complexity here that we'll get to if/when we want to implement on-abort handling, but we haven't been considering that part of the MVP.

[Shubham8287]

• If it's a procedure, delete the row, commit the TX, then invoke the procedure without a TX open.

This is a atmost once gurantee then, we have to also cosider for the case when Host fatals or shutdown after row deletion, procedure will never run.

Edit: nvm, just read, you mentioned it is not required to retry for this case.

[gefjon]

:excellent: