Redfish collections don't implement the /Members route

[edtanous]

Describe the bug
bmcweb Redfish collections appear to be modeled incorrectly according to the specification. Because the Members property within a collection is simply a list of resource references, with AutoExpandReferences enabled, Redfish expects that the equivalent /Members url to also return just the collection.

This subtlety isn't captured very well in the spec that I can find without looking at the OData XML, although it is eluded to in section 8.8

... if a client adds a member to the resource collection at /redfish/v1/EventService/
Subscriptions , it can send a POST request to either /redfish/v1/EventService/Subscriptions or /redfish/
v1/EventService/Subscriptions/Members .

This implies that everywhere we have a collection, we also need a URI route to handle the POST (and maybe the GET) on /Members as well

This is causing us to fail the newly added REQ_POST_CREATE_TO_MEMBERS_PROP test.

This means that EVERY collection within bmcweb needs to change. At some point I'd like to get some more concrete wording in the specification to ensure that this is correct. Considering that we haven't hit this before, it seems to mostly just be a compliance issue.

Environment
What OpenBMC platform was this found on?
Issue exists on all platforms. Tested in Qemu.

What specific OpenBMC versions did you use?
9f410ccf2825825c8a3dafed00eb11aef4ffe2da

To Reproduce
Steps to reproduce the behavior:

1. Boot system in qemu
2. Run Redfish protocol validator with

python3 rf_protocol_validator.py --no-cert-check --user root --password 0penBmc -r https://192.168.7.2 --log-level DEBUG --avoid-http-redirect

3. Observe REQ_POST_CREATE_TO_MEMBERS_PROP test failing.

Is this a regression
No

[gtmills]

Recently ran the protocol validator, I see this too.