Revamp and fix errors in parameters.md

[MantisClone]

Motivation

This PR removes several configuration examples that are no longer correct. This PR also attempts to revamp the parameters.md to more fully explain all the ways to configure Ocean.

[Update by trentmc: All issues should be linked to issues. This PR addresses some of #523. Therefore let's consider it a PR to help towards that issue.]

Changes proposed in this PR

• Removed the example where Ocean() is instantiated with "no input". This ability was removed in #336
• Removed "1. dict input, filled from envvars". Replaced with simpler examples, see below. Previously, this example used envvars to populate a config dict that is then passed to Ocean(config_dict) without first instantiating a Config object. This is removed for two reasons:
  • Creates confusing dynamic between envvars and config dict. Only one or the other is strictly required. When both are provided, envvars override config_dict. This order of precedence deserves its own dedicated section.   * When passing a config_dict directly to the Ocean() constructor without first instantiating a Config instance, only 3 config options are supported: network, metadataCacheUri, and providerUri. All other options are not supported, meaning that if they're included in the config_dict, they are ignored and are set to default values instead. Technically, the user could still use envvars to set the non-supported options but this should be covered in the yet-to-be-written order of precedence section.
• Added "1d. Config object input, filled using config dict". This is a simplified example that shows how to use config dicts.
• Added "2. dict input (deprecated because it doesn't support all config options)". This is a simplified example that shows how to pass a config dict directly to the Ocean() constructor. This is marked deprecated and moved to the bottomof the file. I believe we should remove the ability to pass config dicts to Ocean and thus eliminate duplication between Config and Ocean. Corollary: fixing to support all options would create more duplication.
• Added "1a. Config object input, filled from ExampleConfig (recommended)" where the Config instance is provided by ExampleConfig.  I believe @trentmc referred to this as "the import way". This example is recommended because it requires only a single envvar and ensures that users receive sensible defaults based on the chain_id.  No other config method provides this. Hence, it is inserted near the top of the file.

[MantisClone]

Next Steps

The current draft is still missing sections that would greatly clarify how configuration works:

1. Order of precedence (ie. "if I provide an envvar, a config.ini, and a config_dict containing different values for the same option, which one wins?")
2. Table of all config options (columns for envvar names, config.ini names, and config_dict names)

[MantisClone]

I must set this work aside for now. My v4 tasks, especially https://github.com/oceanprotocol/contracts/issues/348, are a higher priority.

[trentmc]

[David, above] I must set this work aside for now. My v4 tasks, especially oceanprotocol/contracts#348, are a higher priority.

[Trent, in #523] (This) PR had been put on hold for V4. However that was before these issues were flagged as a bug - it's a real problem if a dev wants to use any network! So we need to reconsider doing it sooner.

@DMats I defer to you to balance (a) getting something basic for V4, so others aren't held up, then (b) wrapping this one up and the rest of #523. I see it as a big problem.

[calina-c]

@DMats is this still a draft? Do you think you can finish it soon, or maybe Maria can take over since she's on ocean.py these days?

[MantisClone]

@calina-c Yes, this is still a draft. I'm hoping to tackle this late next week after I've finished with https://github.com/oceanprotocol/provider/issues/226

[calina-c]

@DMats are you fine with closing this? I don't think it applies anymore and I doubt there is much code able to be reused directly. Maybe we can keep the branch for inspiration but close the PR without merging?

[MantisClone]

@calina-c I think this PR is still relevant. I'll double-check that all the changes I made are still true in v4, implement the next steps, and mark this ready for review.

[MantisClone]

@calina-c I took another look at this today. I retargeted it for v4main. I think we should merge it as is because it's more correct than what was there before, even though I didn't add a section about "Order of precedence" or a "Table of all config options"

Reading through #523 again, I remember that I wanted to tear out the ExampleConfig and fix the Config, but I think that work should be scheduled separately.

[trentmc]

This PR is since Sep 2021. It's not big. Is it getting merged, or should it just be closed?

[LoznianuAnamaria]

@mariacarmina Is this PR still relevant? If yes, please pick up the relevant parts/code and merge it. If not let's close it. Thank you!

[MantisClone]

Superseded by #953 (nice work @calina-c! :raised_hands: )