Updates to Gateway doc topic

[denyeart]

Update to Fabric Gateway doc topic.

Signed-off-by: David Enyeart [email protected]

[joshhus]

@denyeart I thought there was a concept of a single Fabric Gateway peer that now manages Tx proposals and endorsements coming in to the network. Your edits seem to indicate that is not the case, and instead there are many "gateway" peers running the Fabric Gateway service - one per organization perhaps? Suggest clarifying that in your update.

[joshhus]

@denyeart Suggest you take another shot at this part, you have several tangential points that are not part of this main point and create somewhat of a run on - that endorsements come from peers in various orgs, that the service runs within a peer, and we could say they do more than gather endorsements right.
Requirements previously placed on the client SDKs, such as gathering transaction endorsements from peers of various organizations, are delegated to the Fabric Gateway service running within a peer ...
So try something like -
Requirements previously placed on the client SDKs, such as managing the transaction endorsement process, are delegated to the Fabric Gateway service running on [which peer(s)?] ... (at the end state which peer(s), rather than "a" peer, since it seems important to mention where the service runs) ... `

[denyeart]

@joshhus a user can decide to enable gateway on a subset of peers, but I think it will be most common to simply have gateway enabled on all the peers. The client then decides which gateway peer to transact with. Different clients can pick different gateway peers. And in some cases the gateway peer endpoint will actually be a cluster of gateway peers that are load balanced, so the client may not even know which gateway they are communicating with currently.

Since it is already merged, please go ahead and do a pull request with any changes that you suggest, but note that Josh Kneubuhl intends to add some wording about the concept of a load balanced endpoint.