Issue:
refactor(scheduler): improve code reusability and consumer logs

## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [ ] Bugfix
- [ ] New feature
- [ ] Enhancement
- [x] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->
This PR contains changes to address the problems listed in #3711, namely:

1. Updates `ProcessTrackerExt::make_process_tracker_new()` method to accept a `tag` parameter in order to increase reusability.
2. Moves the `PTRunner` enum to the `diesel_models::process_tracker` module and renames it as `ProcessTrackerRunner`.
3. Makes use of the `ProcessTrackerExt::make_process_tracker_new()` method to construct all instances of `ProcessTrackerNew` within the codebase.
4. Move `ProcessTrackerExt::make_process_tracker_new()` as `ProcessTrackerNew::new()` method.
5. Removes a redundant `update_process_tracker()` method from the `ProcessTrackerInterface` trait in favor of the `update_process()` method from the same trait.
6. Moves the `reset()`, `retry()` and `finish_with_status()` methods from `ProcessTrackerExt` trait to `ProcessTrackerInterface` trait.
7. Update the business status insertion/updation logic to reduce cardinality of the business status column in the resulting process tracker table.
8. Adds/updates logs that would be displayed when specific parts of the scheduler execution fails.

## Motivation and Context
<!--
Why is this change required? What problem does it solve?
If it fixes an open issue, please link to the issue here.

If you don't have an issue, we'd recommend starting with one first so the PR
can focus on the implementation (unless it is an obvious bug or documentation fix
that will have little conversation).
-->
Resolves #3711.

## How did you test it?
<!--
Did you write an integration/unit/API test to verify the code changes?
Or did you test this change manually (provide relevant screenshots)?
-->
Most of the changes involve moving existing code around, which should not affect the functioning of the scheduler, which I've verified by confirming the correct functioning of the payment sync workflow: the workflow now successfully completes with a business status of `COMPLETED_BY_PT` (only) instead of also including the process tracker ID in the business status.

### Sanity testing of process tracker with payments sync workflow

1. Disable any incoming payment webhooks from the connector with which a payment will be created in the next step.
2. Create a payment with a connector such that the payment reaches the processing state. 
3. Check if the process tracker performs a payments sync successfully and updates the status of the payment to either succeeded or failed:

   1. Immediately after creating the payment, you should see an entry in the `process_tracker` table with status `new` and business status `Pending`. The task should be scheduled to execute in a few minutes' time from the time of creation of the payment.
   2. Once the producer picks up the task, the status should be `processing` and business status remains same.
   3. Once the consumer picks up the task, the status should be `process_started` and business status remains same. If the execution of the task completes quickly enough, you might not notice this status transition.
   4. Once the consumer has successfully completed the execution of the task, the final status should be `finish` and business status should be `COMPLETED_BY_PT`.
   5. If you perform a payments retrieve after the execution of the task has completed, the payment intent's status should now be updated to a succeeded or failed state, as reported by the connector.

### Screenshots from local manual testing

- Screenshot of process tracker entry in database after successful payment sync workflow execution:

  <img width="1200" alt="Screenshot of process tracker entry in database" src="https://github.com/juspay/hyperswitch/assets/22217505/7be2948e-e666-4d02-9003-306512c39d5c">

As for the logs, I've verified that logs are shown when there are consumer workflow execution errors:

- Screenshot of error log displayed when the process tracker entry in the database table contains a value that does not correspond to a valid `ProcessTrackerRunner` variant:

  <img width="800" alt="Screenshot of error indicating invalid workflow runner name" src="https://github.com/juspay/hyperswitch/assets/22217505/2057e83d-873d-4d5c-8d79-b3e349012155">

  This can be used to identify if an old version of the `consumer` service is deployed with a relatively newer version of the `router` service with newer process tracker workflows.

- Screenshot of error log displayed when the `email` feature is enabled on the `router` service, but disabled on the `consumer` service:

  <img width="800" alt="Screenshot of error indicating email feature being disabled" src="https://github.com/juspay/hyperswitch/assets/22217505/cca4ab95-9ae6-4eb0-820d-3232f0fc1f3f">

  This does not typically occur in our hosted environments, since we run builds/images with most (if not all) features enabled.


## Checklist
<!-- Put an `x` in the boxes that apply -->

- [x] I formatted the code `cargo +nightly fmt --all`
- [x] I addressed lints thrown by `cargo clippy`
- [x] I reviewed the submitted code
- [ ] I added unit tests for my changes where possible
- [ ] I added a [CHANGELOG](/CHANGELOG.md) entry if applicable


Resolution:
<think>
PR Context:
- Title: chore(process_tracker): use `const` instead of `String` for `business_status`
- Merged: 2024-06-14T11:53:19Z
- Files changed: 14 files
- Commits: 3 commits

Implementation approach:
## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [ ] Bugfix
- [ ] New feature
- [ ] Enhancement
- [x] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->

When below command is executed in sandbox DB, we get a set of "distinct" `business_status`es that is specified for process tracker:

```sql
SELECT DISTINCT(business_status) FROM process_tracker;
```

For debugging and fun, execute to l
</think>

To implement this, you'll need to modify:


**Detailed Implementation:**


**Commit 1:** chore(process_tracker): use `const` instead of `String` for `business_status` (#4849)
Co-authored-by
Files to modify:


**crates/diesel_models/src/process_tracker.rs**
  Add:
    - mod: pub::business_status

**crates/router/src/bin/scheduler.rs**
  Modify existing code

**crates/router/src/core/api_keys.rs**
  Modify existing code

**crates/router/src/core/payment_methods/vault.rs**
  Modify existing code

**crates/router/src/core/refunds.rs**
  Modify existing code

**crates/router/src/core/webhooks/outgoing.rs**
  Modify existing code

**crates/router/src/db/kafka_store.rs**
  Modify existing code

**crates/router/src/types/storage.rs**
  Modify existing code

**crates/router/src/workflows/api_key_expiry.rs**
  Modify existing code

**crates/router/src/workflows/outgoing_webhook_retry.rs**
  Modify existing code

**crates/router/src/workflows/payment_sync.rs**
  Modify existing code

**crates/scheduler/src/consumer.rs**
  Modify existing code

**crates/scheduler/src/consumer/workflows.rs**
  Modify existing code

**crates/scheduler/src/db/process_tracker.rs**
  Modify existing code