[docs] Minor tidying for ddev pull platform PRs #4441 and #4426

[mattstein]

The Problem/Issue/Bug:

Documentation guy is too slow right now and trying to catch up.

How this PR Solves The Problem:

This makes some minor edits for consistency and hopefully clearer phrasing about how databases are handled in the Platform.sh integration.

I brought this up to date with the master branch and had to fix a conflict in docs/content/users/providers/platform.md, which I think looks good and doesn’t omit any improvements. But you may want to double-check.

Manual Testing Instructions:

Preview changes locally or inspect the automatic build:

• Commands → get
• Platforms → Platform.sh → Designating a Primary Database

Automated Testing Overview:

n/a

Related Issue Link(s):

• Improve output of ddev get in failure cases and add --verbose flag #4441
• Platform integration: Download all databases, Allow a primary relationship for the main 'db', fixes #4415, fixes platformsh/ddev-platformsh#59 #4426
• Audit documentation for consistency, accuracy, and flow #4188

Release/Deployment notes:

n/a

[rfay]

Thanks for the multiple efforts on this. It's hard (and was hard to implement :) ).

But since it only matters to people with more than one db, it probably should be skippable by ordinary folks.

I should have spent more time explaining the 3 cases:

1. One database upstream: Gets downloaded into 'db', nothing required of the user, they don't have to even think. This is the most common case.
2. Multiple databases upstream, PLATFORM_PRIMARY_RELATIONSHIP set: PLATFORM_PRIMARY_RELATIONSHIP's db goes into 'db'. All other databases are pulled and they are named as they were upstream.
3. Multiple databases upstream, PLATFORM_PRIMARY_RELATIONSHIP not set: All databases are downloaded and loaded into databases with the same names they have upstream.

[rfay]

I have a hard time capitalizing 'Bash' but can live with it.

The reality is I have a hard time with 'DDEV' :)

[rfay]

Since this won't matter to the vast majority of people, we may want to calm it instead of making it a major header. That's why it was calmed into bullets before; it doesn't matter most of the time, most people have one database.

Suggested change

	All databases for your Platform.sh project will be pulled locally, with each name matching its remote. When you have more than one, you can optionally tell DDEV which to use as the primary and load into the default `'db'` database.
	If you have just one database on Platform.sh, it will be pulled and loaded into the local default database named 'db'.
	However, if you have more than one database on platform.sh,
	all databases will be pulled locally, with each name matching its remote. If you have more than one, you can optionally tell DDEV which to use as the primary one and load into the default `'db'` database.

[mattstein]

I was attempting to serve the same goal with my edit, using a subheading that would immediately signal to someone they could skip the section, and with the first sentence again reiterating that it’s a situation for multiple project databases only.

While this visually softens it, I’d argue that it assumes someone will read everything here and makes it harder to skip.

In the interest of clarity and completeness, though, I like your list above and would rather rewrite this into a “Managing Multiple Databases” section that blends your three-point list above with the example here designating a primary.

[rfay]

I'm fine with however you want to do it, knowing what you know. Thanks! Sorry this one is so painful.

[mattstein]

Not at all, it’s an interesting feature to describe simply! I’ll counter-suggest something again shortly.

[mattstein]

Alright, another stab: 1c0d63e

I used my theoretical understanding to try and clarify why you may want to designate a primary database, since it’s optional.

[rfay]

Thanks!