Tweaks to AlgorandClient:

[robdmoore]

• Rename AlgoKitClient to AlgorandClient and added static construction methods
• Added fluent with* methods to AlgorandClient to allow for fluent configuration
• Extracted client related stuff to ClientManager and account stuff to AccountManager and added extra functionality to both
• Add transaction and confirmation to the result of sending a single transaction for better ergonomics
• Added ability to specify suggested params and create a copy of suggested params when providing it
• Moved classes to types directory
• Added getAccountInformation to make tests terser (this method should have been added ages ago)
• Incorporated client into testing fixture
• Changed all possible bigint | numbers' to number (where it's impractical for them to hit 2^53)
• Incorporated TransactionSignerAccount with TransactionSigner to allow for terser code
• Rename ID to Id for consistency with rest of algokit utils

There is a txn dead error in the tests to do with valid round calculation that needs to be resolved and I haven't made any changes to composer yet, but there are some I want to suggest, this covers everything else though.

[joe-p]

All looks good to me but ditching bigint does make me nervous. The SDK is going to all bigint for good reason imo. The more I think about I think having just bigint for all the numeric types makes the most sense (not even number | bigint). Most basic reasoning being that it's more representative of the actual data type. Also, while it's true that given how things currently work it's unlikely we'll need it, there could be changes in the future that would end up breaking deployed code (for example, supply cap increase or changes to how app/asset IDs are derived). There also could be forks of Algorand that would want to use this library.

Also having some places where bigint is used and some places where its not for the same underlying data type (uint64) can be a bit confusing

There is a txn dead error in the tests to do with valid round calculation that needs to be resolved

Presumably you fixed this? Tests seem to be passing for me.

[robdmoore]

bigints are painful to work with, my vote is for using number for things we know will never be > 2^53, but happy to follow consensus from broader group of stakeholders.

The test error I get is URLTokenBaseHTTPError: Network request error. Received status 400 (Bad Request): TransactionPool.Remember: txn dead: round 418 outside of 397--407. As far as I can tell a transaction within a group is getting conflicting rounds.

[joe-p]

bigints are painful to work with, my vote is for using number for things we know will never be > 2^53, but happy to follow consensus from broader group of stakeholders.

Consensus on devrel team was that it was better to use bigint everywhere. I agree they can be annoying, especially when working with numbers, but if everything is a bigint this should really be a problem. It also makes behavior much more predictable knowing most numbers should be bigints

The test error I get is URLTokenBaseHTTPError: Network request error. Received status 400 (Bad Request): TransactionPool.Remember: txn dead: round 418 outside of 397--407. As far as I can tell a transaction within a group is getting conflicting rounds.

Ah ok I was able to reproduce. Previously I was just running the client test by itself which was passing. When you run the full suite you get tests in parallel which affect the blocks. We just need to provide a wider window for testing.

[robdmoore]

Cool, can I make a suggestion that when receiving data we accept number | bigint, but when relaying information we provide bigint. I guess the problem may occur where we have a field that can be both though so if there are cases like that it may be better to just be consistent as annoying as bigint's are to deal with?

[joe-p]

I made the change to just bigint. If it becomes a source of a lot of developer problems then we can re-evaluate and add a number union. I think it's easier to add a number union than to remove it.

I'll be merging this PR and recording bootcamp content with the current state of the base branch.