Log unrecongnized resource quota parts instead of returning an error

[tcallan]

Fixes #1137

An alternate solution (or possible addition to this change) would be to capture the resource quota parts that were triggering the error. The parts in question are not useful to me and I'm not sure if they are generally useful so I didn't make that change.

[heaths]

@JeffreyRichter do you see any problem with this? Cosmos is sending back a header value we weren't expecting, and rather than err (not the caller's fault) we simply warn (part of the tracing)?

[JeffreyRichter]

I'm missing the full context on this, but I think not erroring is correct. I also think that not warning may also be correct. What is the value of warning? Would you also warn if an undocumented response header came back from the service?

[tcallan]

FWIW, the warning is there mostly out of excessive caution, just in case it happens to be useful to someone, because I'm relatively unfamiliar with this code. I have zero objections to removing it.

Edit: I went ahead and removed the warning.

[heaths]

BTW, we squash-merge so your fork's main will be different than the upstream main. I recommend always creating a topic branch in your fork and open a PR to merge that into main, such that your main is always in sync - if not behind, but fast-forwardable - with upstream main.