Issue title: Error in the block update order or intentional behavior?
 Issue body: ### Expected behavior

I wanted to build a system that detects if a sulker box has been opened and then sends out a redstone signal.
When the shulker box is opened, the item inside the dispenser to the right of the shulker box moves into the hopper and thus delivers the desired signal.
On vanilla Minecraft (1.19.2) it works perfectly fine:

![Vanilla_Behavior](https://user-images.githubusercontent.com/50832022/194624472-8cdc57f9-d350-49a4-8545-59eb4d68a3ea.gif)

### Observed/Actual behavior

On my paper server, no Redstone signal occurs when using the same design:

![Paper_Behavior](https://user-images.githubusercontent.com/50832022/194624434-30de35b4-178a-4629-9fb5-ea765eaad1bd.gif)

I have tested the system on the paper server with the settings 
`redstone-implementation: EIGENCRAFT` and 
`redstone-implementation: VANILLA `
Both without success.
My question is, is this a bug, an intentional behavior or did i miss a setting somewhere?

### Steps/models to reproduce

**Here is a schmatic to recreate this behavior:**
[Shulker_update_detec.zip](https://github.com/PaperMC/Paper/files/9736529/Shulker_update_detec.zip)

The hopper below the dropper is filled with items so it can't pull any more items from the dispenser above.
![grafik](https://user-images.githubusercontent.com/50832022/194625086-65428963-bca3-403b-9feb-56f15aed667e.png)

The dropper above the hopper contains a random item that cannot be picked up by the hopper below
![grafik](https://user-images.githubusercontent.com/50832022/194625298-b6d6aa39-df2a-41e7-8dc2-47719eeb902c.png)

The hopper dispenser combination also contains a random item to swap back and forth.
![grafik](https://user-images.githubusercontent.com/50832022/194625445-9e418c13-cf3a-4aa7-9535-fc388cb8382e.png)

The content of the shulker box does not matter

The result of opening the shulker box can also be simulated by removing and placing the redstone dust on top of the redstone block (this works also only in vanilla):
![Vanilla_Behavior_2](https://user-images.githubusercontent.com/50832022/194627728-d606690c-8d71-4ad5-9aaf-41e918499ea3.gif)


### Plugin and Datapack List

`/plugins`: none
`/datapack list`: vanilla & file/bukkit

### Paper version

`/version` output:
This server is running Paper version git-Paper-199 (MC: 1.19.2) (Implementing API version 1.19.2-R0.1-SNAPSHOT) (Git: 77a50b9)
You are running the latest version
Previous version: git-Paper-198 (MC: 1.19.2)

### Other

_No response_
 Comments: 
 Comment 0: I can replicate this :+1: Specifically interesting is the fact that this seems to be a paper-only issue.
The contraption works fine on spigot.
 Comment 1: After looking deeper into this (and loosing half my brain cells during the process) this is "abusing" a rather fun bug in hoppers (during which they still actively pull items out of containers above them even if they cannot hold any item).

Paper fixes that as part of the paper hopper optimisation logic. I doubt that fixing this is in scope of paper sadly.
I am sure some core-team or developer member can comment here as well to confirm my suspicion, however I doubt we will be able to help you here as such a contraption might just not be in the scope of paper.
 Comment 2: I'm probably a bit rambly as I'm outta spoons for today, long term goal has always been to restore parity with vanilla, but, given that we're layers down the stack, each fixing edge-case issues; It also gets ultra weird when the behavior is technically a bit of a bug.

In terms of priority, this is probably all the way down there on the list, along with every other redstone parity issue; If somebody wants to submit a PR, I'm willing to look at it, but, I don't think that it could drop a performance patch being such an edge-case thing, at best this would be a small trivial method call with minimal cost to reintroduce the "issue", or a config option


{'source': 'GithubIssues', 'repo_name_with_owner': 'PaperMC/Paper', 'issue_id': 1401572893, 'repo_stars': 7351.0}