scrum master product knowledge

None. If the Scrum Master has in depth knowledge of the product, I would wonder if the product owner is doing his job himself. An exception appies of course if the person who is Scrum Master is part of the Dev Team as well.
The Product Owner is responsible for the product, and the Scrum Master for the process.
Of course a minimal product knowledge can help the Scrum Master to follow discussions.

> how much in depth knowledge of the individual products is the scrum master expected to obtain and retain?

Only as much as is needed to remove or forestall impediments, and to help the team achieve the Sprint Goal. Investing a Scrum Master with greater product knowledge could arguably be wasted effort.

He or she can have the memory of a goldfish as far as specific product requirements are concerned. A good Scrum Master is more likely to harvest experiences by abstracting patterns from them, and which can then be used to service teams across multiple problem domains. It's an in-depth knowledge of the Scrum Framework, and experience of how best to implement it in a given situation, that is needed.

> A scrum master may have, and probably does have, multiple teams (three to four or more) spread across separate and unrelated products.

In practice, I have never seen a person who can fulfill the SM role in any quality way for more than 2 teams. I also have heard many horror stories from others about having 3 or more teams. Even theoretically, I could only be ok with 3+ teams *if and only if* the SM is very advanced in Scrum, AND if the Scrum Teams themselves are very advanced/skilled in practicing Scrum.

As to the original question, I've personally seen SM's do well with product knowledge in their role regarding:

<snipped from Scrum Guide -- not a contiguous snip/quote>
Scrum Master Service to the Product Owner...
The Scrum Master serves the Product Owner in several ways, including:
* Finding techniques for effective Product Backlog management;
* Helping the Scrum Team understand the need for clear and concise Product Backlog items;
* Understanding product planning in an empirical environment;
* Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
* Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team
The Scrum Master serves the Development Team in several ways, including:
Coaching the Development Team in self-organization and cross-functionality;
Helping the Development Team to create high-value products;
Removing impediments to the Development Team’s progress;
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
Helping employees and stakeholders understand and enact Scrum and empirical product development;
Causing change that increases the productivity of the Scrum Team;
</snipped from Scrum Guide -- not a contiguous snip/quote>

So, while I've found that product knowledge helps with all of the above, it's not absolutely required to fulfill the role of the SM well. The main reason product knowledge is helpful with the above is that, when the SM is teaching the team effective PBL techniques and empirical product planning techniques, it's very helpful to couch that advice in the current context of the current product.

Now, if you have an SM that is able to fulfill the time required to fulfill the SM role well, they will naturally gain enough of the product context to complete the above in a few sprints. OTOH, if you have an SM who has 4 teams and all they do is "run from meeting to meeting", then they will likely never gain enough product context. But the root cause of this 4 teams problem is not lack of product knowledge, it's the lack of knowledge/support/respect from the org for the SM role. So, get the org on board with 1-2 teams per SM(without a lot of non Scrum responsibilities), and the product context will occur naturally, and the SM will be more effective.