KV prefix handling

[aricart]

[FEAT] Properly support KV across accounts:

a sample server configuration:

accounts: {
      A: {
        jetstream: true,
        users: [{ user: "a", password: "a" }],
        exports: [
          { service: "$JS.API.>" },
          { service: "$KV.>" },
          { stream: "forb.>" },
        ],
      },
      B: {
        users: [{ user: "b", password: "b" }],
        imports: [
          { service: { subject: "$JS.API.>", account: "A" }, to: "froma.>" },
          { service: { subject: "$KV.>", account: "A" }, to: "froma.$KV.>" },
          { stream: { subject: "forb.>", account: "A" } },
        ],
      },
    },

In the above:

• A exports:
  • Its JetStream API - required to use KV
  • A service all subjects relating to KV
  • A stream
• B imports:
  • The JetStream API
  • The KV subjects, using a prefix
  • The prefixed stream

In ordered to access the KV, the client in B:

• Creates a connection setting the inboxPrefix to forb (this will force NATS to know that subscription interest on forb.> is required by account B and allow the ordered push consumer to work for watches and history.
• Using the same connection, the client creates a JetStreamClient, setting the option apiPrefix to froma, JetStreamManager requests to setup the KV, etc, will now flow to the account's A JetStream.
• KVs created with that JetStream will now properly target buckets in A.

[CHANGE] internal Bucket.create now requires a JetStreamClient instead of a NatsConnection - this allows propagation of the JetStream options to the KV, which enables prefixes (from the NatsConnection) and apiPrefix from the JetStreamClient to be properly honored by the Kv.

[FIX] consumer options ignored inboxPrefix connection option when auto-generating an inbox for a deliverTo, this, in turn, prevented things like watch/history from working on across accounts because in order to circumvent consumer issues across accounts a stream must be exported, and subscriber must use this prefix in order to receive messages. Possibly this is incorrect but requires current consumer across account strategy to be changed to pull (or at least support ordered pull consumers)

[FIX] when re-creating an ordered consumer, the API prefix was incorrectly used as an inbox prefix.

[matthiashanel]

Just a few questions and a name change

[matthiashanel]

so this.nc. does not have a create inbox function that makes use of the inbox Prefix automatically?
As is the case in go.

[aricart]

no it doesn't - it is just a function. But anywhere it is called in the lib it is honored.

[matthiashanel]

LGTM