tree 62f0c97e3eb291d6b0bf943fa6868bb8624ae056
parent c0bdf22334f859d1d2a522d3841160f579a3cbab
author Ed Tanous <edtanous@google.com> 1657251894 -0700
committer Ed Tanous <ed@tanous.net> 1670365051 +0000

Implement If-Match header in Http layer

If-Match is a header in the HTTP specification[1] designed for handling
atomic operations within a given HTTP tree.  It allows a mechanism for
an implementation to explicitly declare "only take this action if the
resource has not been changed".  While most things within the Redfish
tree don't require this level of interlocking, it continues to round out
our redfish support for the specific use cases that might require it.

Redfish specification 6.5 states:
If a service supports the return of the ETag header on a resource, the
service may respond with HTTP 428 status code if the If-Match or
If-None-Match header is missing from the PUT or PATCH request for the
same resource, as specified in RFC6585

This commit implements that behavior for all handlers to follow the
following flow.
If If-Match is present
Repeat the same request as a GET
Compare the ETag produced by the GET, to the one provided by If-Match
If they don't match, return 428
if they do match, re-run the query.

[1] https://www.rfc-editor.org/rfc/rfc2616#section-14.24

As a consequence, this requires declaring copy and move constructors
onto the Request object, so the request object can have its lifetime
extended through a request, which is very uncommon.

Tested:
Tests run on /redfish/v1/AccountService/Accounts/root
PATCH with correct If-Match returns 200 success
PATCH with an incorrect If-Match returns 419 precondition required
GET returns the resource as expected

Redfish service validator passes
Redfish protocol validator passes! ! ! ! !

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I530ab255259c32fe4402eb8e5104bd091925c77b