Add additional properties when doing conversion for hudi

[rahil-c]

What is the purpose of the pull request

This pr fixes several minor issues with the service which were caught in recent manual and integration testing(see IT pr https://github.com/apache/incubator-xtable/pull/716/files), in order to ensure conversion works for hudi and iceberg and with partitioned tables.

Brief change log

1. When testing conversion for Hudi, ran into a null pointer issue, as its required for hudi to set partition spec, as mentioned in the xtable docs https://xtable.apache.org/docs/how-to. When users are specifying hudi as either source or target they will need to provide partition-spec in the configurations map in the request.

 "configurations" : {"partition-spec" : "..."}

2. In addition another issue which was caught during IT was that when Iceberg is the source format and Hudi is the target, in our documentation we require that users provide us the data path to where the data files resides in an iceberg table. From our docs we mention the following: https://github.com/apache/incubator-xtable/tree/main?tab=readme-ov-file#running-the-bundled-jar

tableDataPath is an optional field specifying the path to the data files. If not specified, the tableBasePath will be used. For Iceberg source tables, you will need to specify the /data path.

Special note

As a follow up we will need also add these changes(around parition-spec and a source-data-path) to the spec pr here: #715

Verify this pull request

Now when running with this change do not see the issue.

IT test pr when ran locally passes #716

[rahil-c]

@vinishjail97

[rahil-c]

unit tests in ci seem to be flaky, as the tests failing are not related to this pr and seem to be related to some spark setup.

When i run those unit tests locally they work fine.

[vinishjail97]

The tests are flaky after merging the previous PR for xtable-service-> #704

[rahil-c]

@vinishjail97 Are you sure though? Im not too sure why that pr would cause a flaky test behavior for XTableSyncTool since its in another module from the REST service module.

It seems like this change that was merged recently was able to run fine on the CI #669

Ill try inspecting the full raw logs but can we try rerunning the ci again for this pr to see what occurs?