[FEATURE] Support stage recompute for Spark clients

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

### Search before asking

- [X] I have searched in the [issues](https://github.com/apache/incubator-uniffle/issues?q=is%3Aissue) and found no similar issues.

### Describe the feature

Once `Uniffle`'s shuffle data read fails, the spark client has its chance to recompute the whole stage.

### Motivation

In a distributed cluster with large number of shuffler servers, it's common for some node to go down, such as:
1. node crash/maintenance due to hardware failures or security patches
2. Pod eviction if deployed in a k8s environment
3. vm/spot instance eviction if deployed in a cloud environment

Uniffle already has provide a mechanism to overcome this issue: the quorum protocol. But it requires multiple replica of the same shuffle data, which increases the network traffic and memory pressure on shuffle server. And the E2E performance may be degraded due to the replication.

I'd like to provide a new way to alleviate the potential node failure(in rare chance). Once the whole stage could be recompute, the Spark App could be resilient to shuffle server node failure.

### Describe the solution

TBD.

A design doc would be added later

### Additional context

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

The issue names no files, tests, or entry points and leaves the solution as TBD. Start by reviewing the Spark client’s stage recomputation behavior and the existing quorum mechanism, then produce the promised design doc that defines the approach and acceptance criteria.

Written by the indexing model from the issue text.