Make parsing the sosreport more resilient if the DB is already imported

[jmittermair]

• If using ML2/OVS, and the OVS DB has already been imported, we can get a lot of necessary information directly from the DB.
• In environments that are running sos 3.8, files such as *dump-tlv-maps* and *dump-groups* are not captured.
• The only information that we really need the sosreport for is to capture the OpenFlow dumps.
• This merge request adds optional annotations to the documentation for users to choose between either collecting both the SOS and DB first, or to first import the DB, start the server, and then import the SOS.
• Thus if an older version of the SOS only has the OpenFlow *dump-flows*, we can still import everything successfully.

[amorenoz]

Thanks @jmittermair for the PR. I'm a bit overloaded right now, I hope to take a deep look at it before EOW

[amorenoz]

Before I go into the code, let me see if I understand the use-case corretly

• If using ML2/OVS, and the OVS DB has already been imported, we can get
  a lot of necessary information directly from the DB.
• In environments that are running sos 3.8, files such as *dump-tlv-maps* and *dump-groups* are not captured.
• The only information that we really need the sosreport for is to
  capture the OpenFlow dumps.

If you don't load the groups before loading the flows, the flow insertion will fail, e.g:

> ovs-ofctl -O OpenFlow15 add-flow test "actions=group:1"
OFPT_ERROR (OF1.5) (xid=0x6): OFPBAC_BAD_OUT_GROUP
OFPT_FLOW_MOD (OF1.5) (xid=0x6): ADD actions=group:1

> ovs-ofctl -O OpenFlow15 add-group test group_id=1,type=all

> ovs-ofctl -O OpenFlow15 add-flow test "actions=group:1" && echo "OK"
OK

Same happens with tunnel TLV mappings. If a flow uses a TLV mapping and the TLV mapping was not created before, the flow insertion will fail.

So, if the sos report has flows that use groups and TLV mappings but does not have the files, there is little we can do unfortunately. However, it's true that there might be setups that do not use TLV mappings or groups, in which case we should not fail.

• This merge request adds optional annotations to the documentation for
  users to choose between either collecting both the SOS and DB first,
  or to first import the DB, start the server, and then import the SOS.
• Thus if an older version of the SOS only has the OpenFlow
  *dump-flows*, we can still import everything successfully.

What I don't understand is how the order of loading DB or sos report will solve this problem.