Docs + MSRV

[ikeycode]

• Some documentation updates
• Establish the tested MSRV and explain influence by Firefox Rust Update Policy
• Add COCDEOWNERS file for future branch protection work.

[leftmostcat]

question: I'm wary of failing CI on typos, given that they're very rarely going to be more than a documentation bug. I'm concerned this would cause far more trouble than it would prevent. Is it possible to get the warnings on the review screen without failing?

[leftmostcat]

nitpick: Lack of newline before EOF makes me sad. (This is really nitpicky, but I actually once ran into a CI bug caused by a missing newline!)

[leftmostcat]

Suggested change

	This repository contains the `ews-rs` Rust crate, home to a number of specialized
	data structures and scaffolding APIs to serialize and deserialize [EWS SOAP API](https://learn.microsoft.com/en-us/exchange/client-developer/web-service-reference/ews-reference-for-exchange)
	requests and responses in a more idiomatic fashion.
	Client libraries can be built atop this crate, as we explicitly focus on the protocol
	format rather than applications specifics such as socket negotiation or stream management.
	The reference implementation for this crate is the upcoming EWS protocol in [Thunderbird](https://thunderbird.net):
	- `XPCOM` encapsulation: [ews_xpcom](https://hg.mozilla.org/comm-central/file/tip/rust/ews_xpcom)
	- C++ protocol bridging: [ews](https://hg.mozilla.org/comm-central/file/tip/mailnews/protocols/ews)
	## Minimum Supported Rust Version
	The `MSRV` for `ews-rs` is currently: `1.62.1`
	Note that the use within `comm-central` may require a different MSRV than demonstrable by the code here.
	For further information please consult the [Rust Update Policy](https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html#minimum-supported-rust-version)
	## License
	`ews-rs` is available under the terms of the [MPL-2.0](https://spdx.org/licenses/MPL-2.0.html) license.
	`ews` is a crate providing data structures and APIs for working with Microsoft's
	[Exchange Web Services API](https://learn.microsoft.com/en-us/exchange/client-developer/web-service-reference/ews-reference-for-exchange).
	## Status
	At present, the focus of this crate is providing Rust equivalents of the data
	structures specified in the EWS reference and API for serializing to and
	deserializing from XML.
	No client is provided for handling HTTP requests or responses, and as such,
	this crate does not provide handling of authentication, server-side throttling,
	or other error conditions. Additionally, it does not include an implementation
	of the Autodiscover protocol or any other means of discovering EWS endpoints.
	This crate was built to support the work-in-progress EWS protocol for
	[Thunderbird](https://thunderbird.net). If you have an interest in using this
	crate and it is missing functionality you need or have ideas for improved
	ergonomics, please get in touch with us.
	## Minimum Supported Rust Version
	The MSRV for `ews` is currently 1.62.1.
	## License
	`ews` is available under the terms of the Mozilla Public License, version 2.0.
	See either our [LICENSE] file or [https://www.mozilla.org/en-US/MPL/2.0/].

suggestion: How does this sound? I reworded bits of it to be more explicit in places, more concise in others. I've omitted direct links to the code in Thunderbird as it's not very good as a reference; there's so much Thunderbird-specific weirdness going on that folks would probably be better off either asking us or reading Microsoft's docs.

[ikeycode]

I actually prefer using SPDX as it's the recognised authority on these things, but eh well :)

[leftmostcat]

My thinking was just to point to a) a local copy, and b) the origin of the license in case of something something SPDX, I don't really know. No strong preference there, though I do think we should keep the local link.

[babolivier]

question: Should we ask for a team to be created on the @thunderbird org (e.g. @rust-codeowners), so we don't need to modify this file when this list needs changing, and so we can share it between repos (e.g. xml-struct-rs)? Or would you prefer each repo has its own independent list of code owners?

[ikeycode]

yes

[babolivier]

Suggested change

	This crate was built to support the work-in-progress EWS protocol for
	This crate was built to support the work-in-progress EWS protocol implementation for

nitpick: Since we're not working on the protocol spec.

[leftmostcat]

Looks good. No strong preference on the source of the license or Brendan's comment about adding "implementation", so approval stands if either of those change.