Currently SolarIn/MQTT encodes datum as CBOR. SolarNode's SolarFlux Upload Service plugin now supports using Protobuf to encode the MQTT payload. It would be useful to be able to do the same thing for SolarIn/MQTT. This would require both SolarIn and SolarNode have access to the same Protobuf schema, which should be variable per source ID. The high-level requirements are:

1. Users can manage any number of configurations that associate a source ID pattern to a Protobuf schema (.proto) resource and define a mapping between datum properties and Protobuf message fields. The source ID must be allowed to be specified as a pattern so that entire classes of sources can share the same mapping. For example a */METER/ style pattern would apply to all meter sources and the associated Protobuf schema would be specific to meter data. Users should be able to manage these configurations via the SolarUser API as well as a UI in SolarUser. The configuration must also support any number of datum property names to Protobuf message fields. The message fields should support dot-style nested property name conventions like location.lat. The datum property classification must also be specified.
2. SolarNode must be able to discover the Protobuf mapping configuration based on a given source ID. Either a dedicated API in SolarIn could support this, or the schema might be publishable as user metadata. Both the schema and the property/field mapping configuration must be provided.
3. When SolarIn receives a datum for a source ID that matches a Protobuf configuration, it will decode the message by copying the fields defined in the property/field mapping configuration into datum properties using the provided property classification. If decoding fails, SolarIn should fall back to using CBOR, in case SolarNode has not yet received the Protobuf schema and is still publishing using the default encoding.
4. When SolarNode needs to publish a datum for a source ID that matches a Protobuf configuration, it will encode the message by copying the properties defined in the property/field mapping configuration into message fields.