support required groupwanted

When the required content is set to "groupwanted", use whatever expression
has been set in groupwanted as the required content of the repo, similar to
how setting required content to "standard" already worked.

doc/bugs/drop_file_denied_with_required__61__groupwanted_and_groupwanted__61__nothing.mdwn

@@ -131,3 +131,5 @@ ok
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 I had, some time ago I synced my phone with it. I stopped because of the painful crippled file system there, and the annex was so large that the phone was slow. But I always wanted to restart annexing, to archive and partially checkout my libraries, and maybe do the phone sync right (probably via a special remote)! It seems to be THE tool as soon as a repo is split over multiple disks.
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/drop_file_denied_with_required__61__groupwanted_and_groupwanted__61__nothing/comment_1_ff2986a884988cdf3782db59325d2a9f._comment

@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-28T17:06:39Z"
+ content="""
+This comes down to this part of preferredRequiredMapsLoad:
+
+	pc <- genmap preferredContentLog =<< groupPreferredContentMapRaw
+	rc <- genmap requiredContentLog M.empty
+
+So for required content, it does not use the group preferred content map.
+
+Should it also use the groupwanted values for required content in this case?
+It kind of makes sense, but I do wonder if someone might have a group that they
+want to use one expression for its preferred content (groupwanted)
+and a different expression for its required content ("grouprequired").
+
+OTOH, I suppose that allowing for the former case now does not prevent
+later adding support for the latter. 
+
+(Also, setting required to "standard" already works, so that's a precident.)
+
+Confirmed that passing the map does fix the behavior, so I'm doing that.
+"""]]