implement other Putmodes for Http Client

[giridher-art]

Which issue does this PR close?

Closes #844.

Rationale for this change

HttpStore::put_opts currently only supports PutMode::Overwrite; PutMode::Create and PutMode::Update return Error::NotImplemented. This means HttpStore can't be used for optimistic-concurrency writes (create-if-absent, update-if-unchanged), unlike every other backend (aws, azure, gcp), which already support both modes.

What changes are included in this PR?

• Implement PutMode::Create and PutMode::Update in HttpStore::put_opts / Client::put, using standard HTTP conditional request headers (RFC 7232) rather than the WebDAV If header (RFC 2518 §9.4), since only ETag/existence conditions are needed and not lock-token semantics:
  • PutMode::Create → If-None-Match: *
  • PutMode::Update(v) → If-Match: "<v.e_tag>"
• Map failed preconditions to the existing crate error types:
  • PutMode::Create + 412 Precondition Failed or 304 Not Modified (some servers return 304 instead of 412 for a failed If-None-Match on PUT) → Error::AlreadyExists
  • PutMode::Update + 412 Precondition Failed → Error::Precondition
• Client::put now takes mode: &PutMode to build the appropriate header before sending the request.
• PutMode::Update without an e_tag set on UpdateVersion returns an error rather than sending an unconditional request.

Are there any user-facing changes?

Yes — HttpStore::put_opts now succeeds for PutMode::Create and PutMode::Update instead of returning Error::NotImplemented. No breaking changes to public APIs; this only adds previously-unsupported behavior.

Note: not all HTTP/WebDAV servers honor conditional headers on PUT (this is optional server-side behavior). Against a server that ignores If-Match/If-None-Match, a write may silently succeed unconditionally instead of returning the expected error — this is a server capability limitation, not something the client can detect in advance.