Nested SLOs do not have their ETags verified on GET

When servicing a GET for a flat SLO (i.e., an SLO that only points to normal objects), the slo middleware looks at the hashes that were recorded when the manifest was created and compares against the ETag for each segment as they are retrieved. This maintains some notion of object integrity; if a segment gets overwritten with different content, slo will truncate the response, and any attempt to start reading again at that offset will 409.

When there are nested SLOs, however, we just check the SLO-ness and never verify that we're looking at the *same* SLO that was there when the parent was created:

$ curl http://saio:8090/v1/AUTH_test/c -X PUT

$ curl http://saio:8090/v1/AUTH_test/c/seg1 -X PUT -d 1234

$ curl http://saio:8090/v1/AUTH_test/c/seg2 -X PUT -d 5678

$ curl http://saio:8090/v1/AUTH_test/c/slo?multipart-manifest=put -X PUT -d '[{"path":"c/seg1"},{"path":"c/seg2"}]'

$ curl http://saio:8090/v1/AUTH_test/c/slo
12345678
$ curl http://saio:8090/v1/AUTH_test/c/slo2?multipart-manifest=put -X PUT -d '[{"path":"c/slo"},{"path":"c/seg1"}]'

$ curl http://saio:8090/v1/AUTH_test/c/slo2
123456781234
$ curl http://saio:8090/v1/AUTH_test/c/slo?multipart-manifest=put -X PUT -d '[{"path":"c/seg2"},{"path":"c/seg1"}]'

$ curl http://saio:8090/v1/AUTH_test/c/slo2
567812341234