[FEATURE] Preserve existing index mappings when updating metadata cache

[seankao-az]

Is your feature request related to a problem? As part of #746 , currently FlintOpenSearchMetadataCacheWriter overwrites the index mapping and does not preserve content written by custom implementation of FlintIndexMetadataService (set by spark property spark.datasource.flint.customFlintIndexMetadataServiceClass). For example, if index already has mappings:

{
      "_meta": {
        "customField1": "customValue",
        "properties": {
          "customField2": "customValue2"
        }
      },
      "properties": {
        ...
      }
}

Then the cache writer would overwrite it to

{
      "_meta": {
        "properties": {
          "refreshInterval": 900,
          "sourceTables": [
            "datasource.database.table"
          ],
          "metadataCacheVersion": "1.0",
          "lastRefreshTime": 1234567890123
        }
      },
      "properties": {
        ...
      }
}

Removing both _meta.customField1 and _meta.properties.customField2.

The cached fields should be added upon the existing mappings, not replace them. Desired outcome for above example:

{
      "_meta": {
        "customField1": "customValue1",
        "properties": {
          "customField2": "customValue2",
          "refreshInterval": 900,
          "sourceTables": [
            "datasource.database.table"
          ],
          "metadataCacheVersion": "1.0",
          "lastRefreshTime": 1234567890123
        }
      },
      "properties": {
        ...
      }
}

What solution would you like? Since OpenSearch index mappings only support the PUT api to replace the whole mappings content, in FlintOpenSearchMetadataCacheWriter.updateMetadataCache, we need to

1. GET current mappings content as json
2. Add fields for metadata cache to the json
3. PUT request for the combined json

What alternatives have you considered? Alternative is to remove FlintOpenSearchMetadataCacheWriter, and instead, have FlintIndexMetadataService take care of the cache write themselves. This approach avoids overwriting as we only update mappings once for each command, instead of twice.

Do you have any additional context? Add any other context or screenshots about the feature request here.