Support S3 API for JetStream

[khalil-omer]

JetStream requires a fast local block storage service. This is great for use cases like KV and for read heavy workflows. However, there are a number of products that are using S3 as the fundamental durability layer and treating disks as just caches, and this pattern could have value for a lot of NATS use cases.

Examples of products using this pattern are WarpStream (Kafka on S3), Neon (Postgres on S3), and Axiom (log analytics).

It could be useful to explore how NATS could potentially benefit from supporting this as a configuration option.

I imagine the basic flow as follows:

1. publish() to NATS server as usual (no change to client libraries)
2. The JetStream instance that received the message tries to write it to S3. If it succeeds, the publish is ack'd. (Batching could be enabled by forcing clients to wait for up to 200ms)
3. The JetStream instance now pushes this write to all other nodes in the cluster like normal so that they can publish it to subscribers/consumers. What's different is that none of the nodes are responsible for persisting the message.

This would be a pretty involved project, but it would unlock infinite and low cost stream scale.

[derekcollison]

We have some thoughts around virtual blocks, which is an approach that could use S3 to offload these when not needed locally.

Timeframe would be 2.12 though..