REF: qos: rule list in policy is too difficult to use

[Isaku Yamahata]

The format of qos policy should be something like
{"policy": {"rules": {"bandwidth_limit": {...}, "dscp_marking": {...}}}}

https://review.openstack.org/#/c/207043/
The patch changed the format of qos policy to something like this
{"rules": [{"type": "bandwitdh_limit", ...}, {"type": "dscp_marking", ...}, ]}
with the rationale that there should be zero-or-one rule per each rule-type.

But the format has the following issues
- there is no guarantee that there is at most one rule per rule-type
  In order to verify that, the list has to be scanned.
- When agent(or backend) programs switch for specific rule-type,
  it has to scan the list to find a rule of a give rule-type
- the format is unfriendly to parser or external tools.(In my case java jaxb)
  The actual variable type of rule needs to be determined by reading ahead
  "type". Then the rule needs to be parsed again.

So the following format is better
{"rules": {"bandwidth_limit": {...}, "dscp_marking": {...}}}
- it is guaranteed that there is zero-or-one rule per rule-type
- it's easy to find a rule of a given rule-type
- parser easily determine variable-type.

[Ihar Hrachyshka (ihar-hrachyshka)]

Note that the patch you refer to was in feature/qos branch. There was no point in time when the previous format was exposed to users. So you propose an API change, not fixing a regression or smth.

[Miguel Angel Ajo (mangelajo)]

Exactly, we can't handle API changes now without introducing backward incompatibilities, may be the day we have microversioning, I'll be of course open to making this better.

[Miguel Angel Ajo (mangelajo)]

I'm moving this to Won't fix for now, let's re-evaluate when we have
microversioning of API.