Reconsider implicit fetching behaviour #994
Description
Context
Various Hiro products: Desktop/Web wallets & Explorer add custom headers to all requests to the API, in order to gain some insights into usage, as well as providing means for a kill-switch, were a critical vulnerability to be found.
Related issues leather-io/desktop#700
Relevance
Some Stacks.js invoke API calls internally. getPoxInfo in @stacks/stacking for example, fee calculation in @stacks/transaction.
Issue
No means of configuring these requests is exposed by the library, and thus, in Hiro's use case, we make requests without the expected headers.
Further than simply adding a configuration, perhaps we should reconsider where exactly stacks.js should, and should not make network requests.
Some packages should be smart, and may warrant side-effect behaviour.
In other cases it might go beyond the role of a given package. For example, should @stacks/transactions contain a broadcast transaction method? Or should it only be concerned with creating the tx payload, leaving the broadcasting to another package (network?)