Add x_maturity

[maximusunc]

• Adds openapi schema with x_maturity to the kp registry.
• Adds logic to the kp registry so external services can request KPs of a specific x_maturity.

#25

[cbizon]

In retrieve_kp_endpoints_from_smartapi, we're only looking at the first element in servers. We should probably take this opportunity to handle all the elements in that list. With multiple environments, one option that people may take advantage of is using the same registration, and pointing to both prod and dev as two server entries.

Also, I think we need to go ahead and implement the TODO on line 174/5 of registry.py and assume maturity is a list.

[maximusunc]

In order to pick the better instance, we need to be able to compare similar services. Right now, the only field that would remain constant between service instances is the infores, which is a relatively new required property. I'll need to add infores to the information we store on each service. Until all services add the infores property, we might lose some otherwise valid kps.

[cbizon]

Yes, that's why infores has been added. I think rather than loosing any, we should create a unique infores for anything that doesn't have one, and then complain to the offending team.

[maximusunc]

Just for clarification, if we create unique inforeses for services that don't have them, we'll potentially be hitting both dev and prod of a service since we couldn't compare them correctly.

[maximusunc]

Just for clarification, if we create unique inforeses for services that don't have them, we'll potentially be hitting both dev and prod of a service since we couldn't compare them correctly.

Actually, if services have added x-maturity and multiple instances, then they would have also added infores, so we're probably fine.