Originating Identity may be null if platform does not support this feature

[DorukAkinci]

To make Unipipe OSB more publicly available and usable for the private use cases, we should convert our codes. Our model has a restriction around this header however the public docs explain that this is an optional parameter. Our OSB should have this parameter as nullable type and CLI should have it as dynamic model (not as strict models like meshmarketplace). Moreover maybe even we can automatically put the context.platform value ourselves if there is an originatingIdentity header or we can check that they are matching because it is mandatory requirement which is described in the API specs.

More info: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#originating-identity

[JohannesRudolph]

I think the CLI already tries to differentiate different profiles, e.g. here:

11:50 $ unipipe list --help

  Usage:   unipipe list <repo>
  Version: 1.3.0 (vnext)      

  Description:

    Lists service instances status stored in a UniPipe OSB git repo.

  Options:

    -h, --help                      - Show this help.                                                                                                                     
    -p, --profile        [profile]  - include columns of context information according to the specified OSB API    (Values: "meshmarketplace", "cloudfoundry")            
                                      profile. Supported values are 'meshmarketplace' and 'cloudfoundry'. Ignored                                                         
                                      when '-o json' is set.

Makes sense to make the broker not assume a specific platform profile when speaking OSB API, though it's fine to have support of all the extra meshmarketplace profile features when explicitly flagged as such. For example we should probably make sure that the metering documentation mentions that this is a meshmarketplace profile feature