Additional adjustments to the Admin classes

[sl-at-ibm]

Fixes #87 .

• Payload to "ListDatabases":
  • fix data types and serialization
  • respect parameters being optional in the payload (i.e. respect fields being omitted)
  • "starting_after" parameter made public (until DB list pagination is managed by the client)
• management of ASTRA_DB_ENVIRONMENT environment variable for tests (needed for some of the items on this PR)
• added a virtual property "Database.Keyspace" (useful for tests but also to client users)
• Astra DB admin: removed in-client keyspace existence check in CreateKeyspace route
• fixed Database's UpdateDBKeyspace implementation (was not working correctly)
  • Extended tests to comprehensively cover the intricacies here (to run manually. I did run them a lot)
• Both DatabaseAdmin* classes' CreateKeyspace:
  • revise overloads: there were boolean/boolean ambiguities with UpdateDBKeyspace and WaitForCompletion Slightly breaking signatures
  • revise defaults: WaitForCompletion had inconsistent defaults across overloads (now always true) Slightly docs-impacting
  • re-order and re-arrange overloads for legibility (and alignment between the two classes)
  • introduce an IDictionary for replicationOptions in the DataAPI class (which affects overloads). Kept overloads minimal. Note: a general dictionary is expected (rationale: it's a very specific use case anyway).
• Fix the hardcoded (prod) DevOps API url from some internal "GetDatabaseAdmin" methods of the AstraDatabasesAdmin class. These are used in the CreateDatabase path.
  • Improved the (manually-run) testing of CreateDatabase to verify. I ran these on PROD as well as DEV to confirm.

@sk-datastax pinging you because of some docs-impacts

[sl-at-ibm]

@a-random-steve several changes but nothing too drastic here, IMO.

[a-random-steve]

looks good once xmldoc warnings are fixed :)

[sl-at-ibm]

Thank you @a-random-steve . I have resolved all warnings, I think, except four of them which the latest push to #120 addresses.

[toptobes]

No real qualms. The only thing I'm unsure of is having updateDbKeyspace and waitForCompletion be top-level boolean params since they can be a bit confusing when not used with named method params.

It's probably out of scope for this PR, but just having something like BlockingCommandOptions which extends CommandOptions and the aforementioned options could be clearer to use.

[sl-at-ibm]

updateDbKeyspace and waitForCompletion be top-level boolean params

I agree it's not the best for the caller @toptobes . There are many PRs in flight right now, so I'd prefer to file this change as a Pre-GA minor fix and merge this one as is, to avoid piling up scopes and extending the lifetime of each PR too much. (still scarred by things like 99 lol). WDYT?

Edit: there, #127 created.