Bug: [BUG] Novalnet connector integration



### Bug Description

Novalnet's connector response for refunds expects below format

```
pub struct NovalnetRefundResponse {
    pub customer: Option<NovalnetResponseCustomer>,
    pub merchant: Option<NovalnetResponseMerchant>,
    pub result: ResultData,
    pub transaction: Option<NovalnetRefundsTransactionData>,
}

pub struct NovalnetRefundsTransactionData {
    pub amount: Option<u64>,
    pub date: Option<String>,
    pub currency: Option<common_enums::Currency>,
    pub order_no: Option<String>,
    pub payment_type: String,
    pub refund: RefundData,
    pub refunded_amount: u64,
    pub status: NovalnetTransactionStatus,
    pub status_code: u64,
    pub test_mode: u8,
    pub tid: Option<Secret<i64>>,
}

pub struct RefundData {
    amount: u64,
    currency: common_enums::Currency,
    payment_type: String,
    tid: Option<Secret<i64>>,
}
```

Which fails at deserialization for a specific case.

```
{
    "result": {
        "status": "FAILURE",
        "status_code": 300079,
        "status_text": "Refund limit exceeded. Please contact our support department at support@novalnet.de"
    },
    "transaction": {
        "amount": 123,
        "currency": "EUR",
        "order_no": "pay_be68heac90b_1",
        "payment_type": "CREDITCARD",
        "refund": {
            "amount": 123,
            "currency": "EUR"
        },
        "status": "CONFIRMED",
        "status_code": 100,
        "test_mode": 0,
        "tid": 2187482476274382
    }
}
```

Under `RefundData` object, `payment_type` is made as a required parameter which is missing in the response for certain scenarios leading to keeping the refund in a PENDING state.

### Expected Behavior

Deserialization should not fail and mark the refund status as PENDING

### Actual Behavior

Deserialization should succeed and mark the refund status to FAILURE in such scenarios.

### Steps To Reproduce

Provide an unambiguous set of steps to reproduce this bug. Include code or configuration to reproduce, if relevant.
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'


### Context For The Bug

_No response_

### Environment

Are you using hyperswitch hosted version? Yes/No
If yes, please provide the value of the `x-request-id` response header to help us debug your issue.

If not (or if building/running locally), please provide the following details:
1. Operating System or Linux distribution:
2. Rust version (output of `rustc --version`): ``
3. App version (output of `cargo r --features vergen -- --version`): ``


### Have you spent some time checking if this bug has been raised before?

- [x] I checked and didn't find a similar issue

### Have you read the Contributing Guidelines?

- [x] I have read the [Contributing Guidelines](https://github.com/juspay/hyperswitch/blob/main/docs/CONTRIBUTING.md)

### Are you willing to submit a PR?

Yes, I am willing to submit a PR!
diff --git a/crates/hyperswitch_connectors/src/connectors/novalnet/transformers.rs b/crates/hyperswitch_connectors/src/connectors/novalnet/transformers.rs
index e35384659d1..2a8b0911dca 100644
--- a/crates/hyperswitch_connectors/src/connectors/novalnet/transformers.rs
+++ b/crates/hyperswitch_connectors/src/connectors/novalnet/transformers.rs
@@ -902,7 +902,7 @@ pub struct NovalnetRefundsTransactionData {
     pub order_no: Option<String>,
     pub payment_type: String,
     pub refund: RefundData,
-    pub refunded_amount: u64,
+    pub refunded_amount: Option<u64>,
     pub status: NovalnetTransactionStatus,
     pub status_code: u64,
     pub test_mode: u8,
@@ -913,7 +913,7 @@ pub struct NovalnetRefundsTransactionData {
 pub struct RefundData {
     amount: u64,
     currency: common_enums::Currency,
-    payment_type: String,
+    payment_type: Option<String>,
     tid: Option<Secret<i64>>,
 }
 

## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [x] Bugfix
- [ ] New feature
- [ ] Enhancement
- [ ] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->
Need to make unused fields in novalnet refund response as optional. This will prevent the deserialization errors. 
It's a configuration done on Novalnet side, only available in prod. Cannot test this specific case in sandbox. cc: @kashif-m 

### Additional Changes

- [ ] This PR modifies the API contract
- [ ] This PR modifies the database schema
- [ ] This PR modifies application configuration/environment variables

<!--
Provide links to the files with corresponding changes.

Following are the paths where you can find config files:
1. `config`
2. `crates/router/src/configs`
3. `loadtest/config`
-->


## 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).
-->
Few fields which are not mandatory in response were made mandatory in the types defined which were causing deserialization when parsing connector refund response.

## 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)?
-->
Curl to test:
```
curl --location 'http://localhost:8080/refunds' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'api-key: dev_LGJYQwEIgppbYvbIuwmQYyHGtMLquJJUujSrP34trbI4k1nnTs1ZyqkG1aI6Nx5N' \
--data '{
    "payment_id": "pay_ahzKGIpLrLjWUsalTs0D",
    "amount": 10000,
    "reason": "Customer returned product",
    "refund_type": "instant",
    "metadata": {
        "udf1": "value1",
        "new_customer": "true",
        "login_date": "2019-09-10T10:11:12Z"
    }
}'
```

## 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`
- [ ] I reviewed the submitted code
- [ ] I added unit tests for my changes where possible
