Changes to the `request_project` method

[shrnkld]

To do:

• [x] add a parameter to request_project to enable selecting the project type:
  1. xquery
  2. hydra
• [x] modify request_hydra_project method to accept one of the following optional parameters:
  1. archival
  2. non-archival
     • [x] set the default option to: non-archival
• [x] set a lower limit for api calls, where minimum purchase possible==1000 queries
• [x] display all pricing info as cost_per_1000_queries eg $0.001/1000 query - TBD
• [x] #43
• [x] remove all usage-limiting features eg time constraints, max calls, etc - TBD
• [ ] #42
• [x] #41

[ConanMishler]

set a lower limit for api calls, where minimum purchase possible==1000 queries

Ok, I had started to document it as 100 queries min, but I'll change it to 1000 min

display all pricing info as cost_per_query eg $0.0001/query - TBD

I think it'll be best to return api_call_cost in terms of cost per 1000 queries, since that is the minimum they can pay. That will also prevent us from having too many zeros before the number of interest (e.g. 0.000000001 ETH)

when a payment is made after the expiry_time has passed, refund the full payment minus gas fees - TBD

I think this one will have to wait till Snode payment processor logic is integrated with payment channel Smart Contract, but I'll document it this way in the API docs.

Thanks for creating the issue!

[ConanMishler]

when a payment is made after the expiry_time has passed, refund the full payment minus gas fees - TBD

This won't be possible till after we have payment channel smart contracts in place. For now, payments made after quote_expiry_time has passed will get half the normal number of API calls awarded. This is basically what the old payment processor did, though in an extremely complex and convoluted way which was mixed up with tier1 vs tier2 Hydra considerations.

the same address should be returned for all available payment networks: eth_address, avax_address and nevm_address

I tried, but failed to get this to happen. The web3 lib code which generates the address for a new web3 account accepts a secret token, which is basically just a cryptographically strong large random number. I thought by passing the exact same secret token to the code that generates eth_address, avax_address and nevm_address, I'd get the same address generated for all 3. It didn't work that way.