Fix clientside storage Whitelists

[Nopey]

About the PR

When a StorageComponent has an EntityWhitelist that filters by a server-only Component, the Client will incorrectly believe items carrying the component do not match the whitelist. This results in a prediction error and erroneous "Can't insert" message.

To demonstrate, try gathering the apples that spawn on Dev with the PlantBag that spawns in the botanist's locker. The following message will appear on master, as the client does not believe Apples are Produce:

Additionally, the Assault Belt has been filtering by the pre-Gun Refactor (#8301) "RangedMagazine" component that was been superceded by BallisticAmmoProvider; this meant both server and client would both incorrectly disallow ammo in the assault belt. This is once again allowed:

Why / Balance

These prediction errors are confusing to new players, and ignored by experienced players; not pleasant for anyone.
Although the Assault Belt change may be argued to effect gameplay balance, it was clearly not #8301's intent to disallow ammunition from being inserted in the Assault Belt.

Technical details

The following is a list of belts, and what previously-serverside component they filter by.
Security Belt:

• Flash
• FlashOnTrigger (as used by flashbangs)
• SmokeOnTrigger (as used by smoke grenades)

Utility Belt:

• SprayPainter

Assault Belt:

• RangedMagazine (has been superceded by BallisticAmmoProvider)

JaniBelt:

• LightReplacer

Chef Belt:

• Mousetrap
• Utensil

Plant Bag:

• Seed (also in Botanical Belt)
• Produce

The Botany components (Seed and Produce) now have trivial (empty) implementations in shared and client.
The remaining perviously-serverside components have been moved to the Content.Shared module, with trivial Shared Systems created as-needed for the components' Access property to reference.
Except for Botany, all data fields on the components are present in Shared (and could theoretically now be used in Clientside code).

Media

• I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

The following components have been moved from Content.Server to Content.Shared:

• SprayPainterComponent
• FlashComponent
• UtensilComponent
• LightReplacerComponent
• SmokeOnTriggerComponent (as used in smoke grenades)
• FlashOnTriggerComponent (as used in flashbangs)
• MousetrapComponent

Changelog
🆑

• fix: Many belts and the plant bag no longer produce an erroneous "Can't insert" and "This doesn't go in there!" messages while inserting certain items such as Produce (plant bag) or Smoke Grenades (security belt).
• fix: Ammunition can once again be stored in assault belts, as was the case before June 2022.

[metalgearsloth]

Shared components need to be networked.

Also given the number of systems this touches this is very likely going to be conflict bait so might be easier to get through being split up a bit more.

[Nopey]

Fixed yaml linter warnings:

• In security.yml, moved repeating from portable flasher's FlashOnTrigger component to TriggerOnProximity, which appears to have been a typo.
• In spray_painter.yml, the whitelist section has been removed. This section is likely a vestige of the spray painter's development, as the C# datafield that would deserialize it is not in commit history.
• Re-did the Botany components, with trivial (no members) on the Shared and Client classes; this avoids introducing the seed prototypes to the client and avoids upsetting the linter.
  The interesting members now remain unmoved in Content.Server.

Content.IntegrationTests was either failing because of the previous botany changes, or was a fluke-- it's now passing locally, so I expect the CI pipeline to pass.

Regarding breaking this work up:
Should each of the (now 6) commits be a seperate MR? that seems like it might make the maintainers' job more difficult, but I can do that.
For now I'm going to push my revised changes here and update the description, but I'll check on this MR in the morning and could certainly break it up then.

[Nopey]

EDIT: the ViewVariables attribute is part of admin/mapper tool for editing entities, not anything to do with networking.

old message, not really relevant

It's unclear to me what networking changes you are requesting.

As an example, the SprayPainterComponent has several members:

• IsSpraying is annotated with DataField, which if I understand correctly allows it to be (de)serialized. Does IsSpraying need networking?
• PickedColor, in addition to DataField, has a ViewVariables field; I believe VV performs networking, with the VVAccess.ReadWrite allowing clients to send read and write messages for this field to the server. Only the server references this field.

Am I misunderstanding what ViewVariables does? Is there a(nother) way of performing networking I am unaware of?

Should I prefer the style used in my Botany changes, where fields remain in Content.Server, and Content.Shared/Client gain trivial (empty) implementations of each component? would cause less breakage, although mirrorcult advised in Discord channel #howdoicode that I should try to "move" components to Shared.

[Nopey]

Should close issue #22686, unless we want additional safeguards against the behavior described where:

1. The player attempts to place an item in a gridinv
2. The client doesn't think the item can go in there
3. The client doesn't bother telling the server they tried!
   If we want the client to ask the server just-in-case the whitelist is bugged on the client, we could keep 22686 open (or open a new, more specific issue)

[Nopey]

Have discovered NetworkedComponent and the wiki 🙃
Going to add it to each shared component, and start thinking about where replication is needed.

NetworkedComponent is sufficient for the creation of components to be replicated, although their fields remain unreplicated.
Is it sufficient to leave the components' fields unreplicated, as no code currently consumes them?
EDIT: thanks for your answer in Discord, leaving fields unreplicated.

[Nopey]

@metalgearsloth could you have a look at this, again?

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[metalgearsloth]

Gonna conflict with #22691 so gonna do that one first.