v1: pool (CXX-3237, CXX-3238)

[eramongodb]

Resolves CXX-3237 and CXX-3238 for the v1::pool component and implements dependent functions in v1::auto_encryption_options and v1::client.

On further inspection, opted to make the v1::pool API more consistent with v1::client API by:

• permitting moveability (no other class in the API is immovable).
• supporting an assign-or-destroy-only state check (for consistency with moveability).
• permitting implicit construction from v1::uri (e.g. v1::client c = v1::uri{"abc"}; <-> v1::pool p = v1::uri{"abc"};).
• supporting .database() to complement operator[] (e.g. entry["db"] + entry.database("db")).

The same T const& -> T change made for the v1::client::options parameter in #1559 is applied to the v1::pool::options parameter to permit moving the APM callback functions. Additionally, database name parameters are changed from std::string to bsoncxx::v1::stdx::string_view for consistency with the removal of the owning internal data member in #1564.

---

The formerly v1::client-specific internal helpers for translating option classes into BSON fields are refactored into their respective components for reusability by v1::pool. The implementation of the v1::pool constructor is deliberately made as symmetric as possible with the v1::client constructor.

Although v1::pool is moveable, we do not support v_noabi <-> v1 conversion due to the potential invalidation of associated client objects (a similar concern to client objects associated with v1::client_session). Similarly, there is no v_noabi <-> conversions for v_noabi::options::pool due to no conversions for v_noabi::options::client (due to .auto_encryption_opts()) or for v_noabi::pool::entry (due to T const& accessors). However, users who want to convert pool options between v_noabi <-> v1 can do so by converting between v_noabi <-> client options instead.

Nevertheless, because the pool API does not expose the client or auto encryption options post-initialization, the initialization of v_noabi::pool can still be refactored to be (partially) implemented in terms of v1::pool; pool options are still handled separately to avoid intermediate deep-copies.

Because pool options are essentially identical to client options, test coverage for the behavior of v1::pool::options mostly deferred to equivalent v1::client:options test cases. The pool option test cases are reduced to ensuring pool-specific code paths are exercised. The option field handlers are already exhaustively tested by v1::client::options test cases added by #1559.

[kevinAlbs]

LGTM. Only minor comments.

[kevinAlbs]

Suggested change

	TEST_CASE("error code", "[bsoncxx][v1][pool][error]") {
	TEST_CASE("error code", "[mongocxx][v1][pool][error]") {

[kevinAlbs]

Suggested change

	// Represent a successfully-constructed mocked `v1::client` object.
	// Represent a successfully-constructed mocked `v1::pool` object.

[kevinAlbs]

Suggested change

	auto const tls_opts_set = GENERATE(false, true);
	CAPTURE(tls_opts_set);

Remove tls_opts_set? Appears redundant with tls_enabled.

[eramongodb]

Whoops. This input value was intended to exercise the "URI does not enable TLS, but TLS options were still set" scenario, but the opts.tls_opts() was not guarded on this properly. Updated both the client and pool tests accordingly.

[kevinAlbs]

Remove file? Or is this intended to isolate compile coverage of mongoc/options/pool.hpp?

[eramongodb]

Yes, this file is acting as the standalone compilation test of the mongocxx/options/pool component.