feat: better approach to client resource management

[sgbalogh]

• Builder pattern for clients
• Clients implement AutoClosable but only shutdown owned resources (executor, grpc channel)
  • resource is owned if it was constructed via a default by the builder
• Clients no longer create each other (no more account -> basin -> stream flow, as it complicates the ownership semantics)
• ManagedChannelFactory, to expose simple util for constructing a channel given an s2 config
• Wrapper on ManagedChannel that implements AutoClosable (only now can I see @ASRagab's wisdom in the original ChannelManager 😛, whoops )
• ManagedReadSession and ManagedAppendSession also now impl AutoClosable
  • they dont close executor/channel, but do attempt to clean up outstanding futures, so as to avoid situations where the executor in which they are running is shutdown first

I think this is a more reasonable approach to dealing with these resources?

    try (final var executor = new ScheduledThreadPoolExecutor(1);
        final var channel = ManagedChannelFactory.forBasinOrStreamService(config, basinName)) {

      // share executor and channel between two stream clients:
      final var streamClient1 =
          StreamClient.newBuilder(config, basinName, "my-stream-1")
              .withExecutor(executor)
              .withChannel(channel)
              .build();

      final var streamClient2 =
          StreamClient.newBuilder(config, basinName, "my-stream-2")
              .withExecutor(executor)
              .withChannel(channel)
              .build();
  }

[sgbalogh]

scheduled executor only impl's AutoClosable starting in 19, so the bump is required (just for the demo, not SDK)

[ASRagab]

TIL

[ASRagab]

@sgbalogh yeah, I think I like this way better. I think I got bogged down in closing the previous channel and managing all the edge cases, this is much cleaner, also more idiomatic I think for these kinds of clients.