disable-noteblock-updates also disables note block redstone and tuning, not just the state recalculation #14369

Expected behavior

block-updates.disable-noteblock-updates is the setting servers with custom
blocks (ItemsAdder, Nexo, Oraxen, …) have to enable, because those plugins
encode block identity in the note block's instrument + note properties and
vanilla's updateShape recalculates instrument from the block below,
destroying that identity.

What one expects from the name and from the use case is: stop the state from
being recalculated. Note blocks should still behave like note blocks for
everything that does not touch instrument.

Observed/actual behavior

Enabling the setting also removes all redstone behaviour of note blocks:

• they no longer play a sound when powered,
• POWERED is never flipped, so observers watching a note block never
  fire — every note block machine, door latch and music contraption on the
  server stops working,
• right-clicking no longer cycles the pitch, so note blocks cannot be tuned
  at all.

For a server that has to enable the setting, this is not a trade-off between
two bugs — it is "custom blocks survive" against "no player may use note
blocks any more".

Where it comes from

NoteBlock checks GlobalConfiguration.get().blockUpdates.disableNoteblockUpdates
in four places. Verified with javap -c on upstream
paper-1.21.10.jar and paper-1.21.11.jar (identical in both):

Only the first two have anything to do with the block state being
recalculated. neighborChanged is pure redstone: it reads the signal, plays
the note and writes POWERED — none of that can corrupt a custom block,
because instrument and note are untouched.

Steps to reproduce

1. block-updates.disable-noteblock-updates: true in paper-global.yml
2. place a note block with air above it, point a repeater at it
3. the note block makes no sound and POWERED stays false
4. place an observer facing the note block — it never fires

Proposal

Split the setting, or narrow it to the two state-recalculating call sites:

block-updates:
  disable-noteblock-updates: true          # getStateForPlacement + updateShape only
  disable-noteblock-redstone: false        # neighborChanged, default false

Keeping neighborChanged alive by default would already solve it for every
custom-block server without changing anything for anyone else. If the current
behaviour is intentional, it would help a lot to say so in the config comment —
right now the name and the comment ("Disables block updates for noteblocks")
give no hint that redstone and tuning go with it.

Workaround for others hitting this

Until then it can be rebuilt in a plugin, and this works — tested on a
staging server with the setting enabled:

BlockPhysicsEvent still fires for the note block (it is raised before
neighborChanged, so the flag does not suppress it). Re-implementing the
vanilla sequence there — compare hasNeighborSignal against POWERED, fire
BlockRedstoneEvent, play the note, setBlockData(data, true) — restores both
the sound and POWERED. setBlockData(data, true) resolves to
setBlock(pos, state, 3), the same flag vanilla uses, so observers behave
identically.

A/B measured with the plugin switch on and off, flag enabled in both runs:

BlockRedstoneEvent itself is not usable as the hook, because vanilla
fires it inside neighborChanged, behind the disabled part.

Plugin list

Reproduced on a production server (ItemsAdder); the four call sites above were
read directly from the stock Paper jars, so this is not plugin-specific.

Paper version

paper-1.21.10 and paper-1.21.11 (checked); the server in question runs
Leaf 26.2, a Paper fork, where the same four call sites are present unchanged.