suspend_barrier5 times out waiting for 4000 input records while
suspending in CI. The log seems to indicate that the connector
is making progress, just slowly under load. We increase the timeout
from 10 to 100s and improve progress logging. If the issue occurs
again, this means there's a real bug somewhere.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

Added configuration for a Lakeflow declarative pipeline. Users can copy the bronze data to their own bucket, see how Feldera works with snapshot_and_follow mode, and contrast with Databricks IVM solution (lakeflow declarative pipelines)

Signed-off-by: Anand Raman <anand.raman@feldera.com>

Signed-off-by: Mihai Budiu <mbudiu@feldera.com>

This commit fixes a severe bug and a less severe race.

The bug: when we fail to make a checkpoint while suspending, we log the
error, but still set pipeline status to Suspended, making it look like the
Suspend succeeded. There are two options for handling this better: (1) go back
to the Running state, giving the user a chance to fix the issue and retry
(not sure what they can do if the disk runs out of space though...),
(2) stop the pipeline and set state to Failed. Like with any other failure,
some progress is lost, but at least we don't mask the error.

The race: when the checkpoint succeeded, there was a brief window after the
checkpoint completes and before we set phase to Suspended when the pipeline's
state was Stopped. This caused tests waiting for the Suspended state to fail,
since they don't expect the Stopped status.

This flaked the cloud `suspend_and_resume_demos` test: a demo reached
`Stopped` carrying `PipelineTerminated` instead of suspending cleanly.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

Make sure a failed suspend is reported as a pipeline failure.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

Signed-off-by: Mihai Budiu <mbudiu@feldera.com>