Fix the corrupted Trie routing tree

The routing table may potentially become corrupted during the routing
table construction as the vector element pointer becomes invalid if the
vector is resized [1

Fix the corrupted Trie routing tree

The routing table may potentially become corrupted during the routing
table construction as the vector element pointer becomes invalid if the
vector is resized [1].

http/routing/trie.hpp#L241:
```
ContainedType& node = nodes[idx];
size_t* param = &node.stringParamChild;
if (str1 == "<path>")
{
param = &node.pathParamChild;
}
if (*param == 0U)
{
L249:
*param = newNode(); // <---
}
idx = *param;
```

Here, `newNodes()` at L249 may resize the vector of `nodes[]` and thus
the reference of `nodes[idx]` becomes invalid and thus the previously
saved the pointer of `param` is invalid.

The similar issue is also at sub_route_trie construction [5].

This problem may be shown during CI/valgrind test depending on the order
of route setups in [2].

For example, for the commit 39574 [3], if `requestsRoutesAssembly()` is
added earlier than `requestRoutesProcessorCollection()`, it causes
CI/valgrind test fails [3].

The error looks like [4].

[1] https://github.com/openbmc/bmcweb/blob/master/http/routing/trie.hpp#L241
[2] https://github.com/openbmc/bmcweb/blob/master/redfish-core/src/redfish.cpp
[3] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/39574
[4] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/39574/comment/15e652e0_f8881ffc/
[5] https://github.com/openbmc/bmcweb/blob/master/redfish-core/include/sub_route_trie.hpp#L160

Tested:
- CI with https://gerrit.openbmc.org/c/openbmc/bmcweb/+/39574 passes
after rebase of having earlier `requestsRoutesAssembly()`.
- Redfish Service Validator passes

Change-Id: I349777dfab65f2d41eb5db25796d82322b3c36cc
Signed-off-by: Myung Bae <myungbae@us.ibm.com>

show more ...

Fix includes

Our includes haven't been enforced by tidy in a while. Run the script,
check in the result, minus the false positives.

Change-Id: I6a6da26f5ba5082d9b4aa17cdc9f55ebd8cd41a6
Signed-off-

Fix includes

Our includes haven't been enforced by tidy in a while. Run the script,
check in the result, minus the false positives.

Change-Id: I6a6da26f5ba5082d9b4aa17cdc9f55ebd8cd41a6
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

OEM Route Handling Infrastructure

Goal of the MR is to provide infrastructure support in bmcweb to manage
the OEM fragment handling separately. OEM schema are vendor defined and
per DMTF resource we

OEM Route Handling Infrastructure

Goal of the MR is to provide infrastructure support in bmcweb to manage
the OEM fragment handling separately. OEM schema are vendor defined and
per DMTF resource we could have multiple vendor defined OEM schema to be
enabled.

The feature allows registration of route handler per schema per OEM
namespace.
Example
```
REDFISH_SUB_ROUTE<"/redfish/v1/Managers/<str>/#/Oem/OpenBmc">(service,
HttpVerb::Get)(oemOpenBmcCallback);
REDFISH_SUB_ROUTE<"/redfish/v1/Managers/<str>/#/Oem/Nvidia">(service,
HttpVerb::Get)(oemNidiaCallback);
```

We can have separate vendor defined route handlers per resource. Each of
these route handlers can populate their own vendor specific OEM data.
The OEM code can be better organized and enabled/disabled as per the
platform needs. The current MR has the code changes related to handling
GET requests alone. The feature only supports requests
where the response payload is JSON.

Tests
- All UT cases passes
- New UT added for RF OEM router passes
- Service Validator passes on qemu
- GET Response on Manager/bmc resource contains the OEM fragment

```
curl -c cjar -b cjar -k -X GET https://127.0.0.1:2443/redfish/v1/Managers/bmc
{
"@odata.id": "/redfish/v1/Managers/bmc",
"@odata.type": "#Manager.v1_14_0.Manager",

"Oem": {
"OpenBmc": {
"@odata.id": "/redfish/v1/Managers/bmc#/Oem/OpenBmc",
"@odata.type": "#OpenBMCManager.v1_0_0.Manager",
"Certificates": {
"@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates"
}
}
},

"UUID": "40575e98-90d7-4c10-9eb5-8d8a7156c9b9"
}
```

Change-Id: Ic82aa5fe760eda31e2792fbdfb6884ac3ea613dc
Signed-off-by: Rohit PAI <rohitpai77@gmail.com>

show more ...