Pst/custom token

[fgamundi]

Add support for multiple different headers - backwards compatible for existing code

[Vervious]

Since go-algorand doesn't support other api tokens this change seems orthogonal and complicates the client. Perhaps we should consider having a Pst fork?

[Vervious]

Hi @fxgamundi, thoughts on us closing this pull request for the aforementioned reason? Or is there a good rationale for this change to be added?

[fgamundi]

Hi @Vervious ! I think it's a good thing for the native SDK to support different token headers other than the built in X-Algo-API-Token. It would make a much easier work to anyone that, like us, has a wrapper on the node so that the calls don't go directly to it, but still have 100% compatibility for the algod REST APIs. Cultivating an environment conducive to the desired proliferation of Algo tokens constitutes the call for integration with external libraries. The allowance of secondary tokens then seems tantamount to the direction of Algorand.

[bjweaver]

Worth noting that the JS SDK supports both X-Api-Key and X-Algo-API-Token, so it would be ideal if the Go SDK did as well.

[rotemh]

For better type safety and to not change interfaces, I rather avoid using the empty interface. Please consider simply adding MakeClientWithHeaders(address string, apiToken string, headers []Header) instead of the combined version. Besides that, looks good.

[fgamundi]

We added the new factory function to create an algod client with headers.
Also modified the client's functions accept additional headers for each specific request, making it on par with the Python SDK.
The best approach that we could think of for this was making the functions variadic, with the headers as the last arg of the functions. This guaranties that the functions can be called without any headers, just one, or a slice of them, making it fully backwards compatible.