Reason

1. ContentPropertyIndexSchema will register plugin index schema with the mapping by types as:
   1. extract path with type date -> DateFieldMapping
   2. extract path with type number -> LongFieldMapping
2. ContentPropertiesExtractor will call ContentPropertyExtractionManagerImpl to extract and mapping stored property jsonString with schemaFields as:
   1. DateFieldTransformation -> return StringFieldDescriptor with StringFieldMapping
   2. NumberFieldTransformation -> return DoubleFieldDescriptor with DoubleFieldMapping
3. Then it tries to adding the field mapping from step 2 by comparing with the registered ones from step 1. It throws warnings of mapping types conflicts. As we have:
   1. DateFieldMapping  vs StringFieldMapping
   2. LongFieldMapping  vs DoubleFieldMapping

 
According to the dev doc, it says type number will be indexed as double, and date can be represented as either String or long, so the above mappings are neither correct in both step 1 and 2.
 

Summary

1. There is no workaround as it requires code changes in confluence to fix this issue. 
2. This issue will not affect the plugin's main functionality
   1. these properties will still be accessible via java code
   2. the issue mainly affect the Confluence lucene index for searching content properties, thus will affect the properties accessible by REST API

Need to fix content property field mappings

The Date field extractor need to use the new `DateFieldMapping` builder.

The Number field should be `DoubleFieldMapping`