Jetpack Block PHP Fixture Tests: Tracking issue for blocks requiring server-side rendering tests

In #19743 we introduced a server-side fixture test for the Business Hours block. The test grabs the serialized markup from the JS-based fixtures tests, and runs the markup through the block's server-side `render_block` function. If a fixture for the server rendering does not exist, one is created. If a fixture exists, then the output of the `render_block` function is compared against the `*.server-rendered.html` fixture.

In this way, we have a (hopefully) fairly simple way of adding tests for the server rendering of blocks, in addition to the existing fixture tests that cover the JS edit and save behaviour.

This tracking issue is to add in similar tests for all the other Jetpack blocks that use server rendering. In #19985 we introduced a generalised approach to running PHP-based server rendered fixtures tests by adding a parent `Jetpack_Block_Fixture_TestCase` class to inherit from when adding a fixture test to the `test/php/extensions/blocks` directory. Instructions are proposed in https://github.com/Automattic/jetpack/pull/20004.

## Steps to add a server-rendered fixture

* Copy an existing PHP block fixture test that inherits from `Jetpack_Block_Fixture_TestCase` (e.g. https://github.com/Automattic/jetpack/blob/HEAD/projects/plugins/jetpack/tests/php/extensions/blocks/test-repeat-visitor.php)
* Save to the same directory with a filename matching the block that you're targeting
* Ensure there are existing `.serialized.html` block fixtures for this block
* Update class names, comments, and the `BLOCK_NAME` class constant to reference the block you're trying to test
* Take a look at the `test_server_side_rendering_based_on_serialized_fixtures` tests and set any server side state or mocks that are required before the dynamic block's render callback is called, and add that code before calling `$this->generate_server_side_rendering_based_on_serialized_fixtures()` to run through generating and testing the server-rendered block fixtures.
* Update the call to `$this->generate_server_side_rendering_based_on_serialized_fixtures()` to include the appropriate slug to match the directory containing the block's code, and the desired extension for the generated server-rendered markup (usually defaults to `.server-rendered.html`)

## Tasks

* [x] See if the approach from #19743 can be generalised in a useful way into utility functions for these tests (addressed in #19985)
* [ ] Ensure that deprecated markup is also picked up by these server-based tests. Deprecated markup that hasn't _yet_ been migrated to the current markup (E.g. an old blog post that a user hasn't gone back to edit) should also result in successful server rendering of the block.

## Blocks that could use tests for their server-side rendering

Note: I haven't included blocks that use a `render_block` function that only loads assets. Each of the below blocks alters rendered markup in some way, so would benefit from fixture tests.

Also some blocks might perform API requests or do other things that could make it harder to get them under test. In some cases maybe this is an opportunity to do some light refactoring. In others, perhaps we should park it until we need to make changes to the block further down the track.

* [x] `jetpack/business-hours`
* [ ] `jetpack/button`
* [ ] `jetpack/calendly` (include deprecations, could be a good one to start with)
* [ ] `jetpack/contact-form` and associated blocks (registered [here](https://github.com/Automattic/jetpack/blob/ef6364966f1d52285c9a111e010d2a9ee178567f/projects/plugins/jetpack/modules/contact-form/grunion-contact-form.php#L246-L246)
* [ ] `jetpack/field-text`
* [ ] `jetpack/field-name`
* [ ] `jetpack/field-email`
* [ ] `jetpack/field-url`
* [ ] `jetpack/field-date`
* [ ] `jetpack/field-telephone`
* [ ] `jetpack/field-textarea`
* [ ] `jetpack/field-checkbox`
* [ ] `jetpack/field-checkbox-multiple`
* [ ] `jetpack/field-radio`
* [ ] `jetpack/field-select`
* [ ] `jetpack/field-consent`
* [ ] `jetpack/contact-info` and associated blocks
* [ ] `jetpack/address`
* [ ] `jetpack/email`
* [ ] `jetpack/phone`
* [ ] `jetpack/donations`
* [ ] `jetpack/eventbrite`
* [ ] `jetpack/gif`
* [ ] `jetpack/google-calendar`
* [ ] `jetpack/image-compared` (just for AMP support?)
* [ ] `jetpack/instagram-gallery`
* [ ] `jetpack/mailchimp`
* [ ] `jetpack/map` (inserts an API key, might need some mocking?)
* [ ] `jetpack/opentable`
* [ ] `jetpack/pinterest`
* [ ] `jetpack/podcast-player`
* [ ] `jetpack/premium-content`
* [ ] `jetpack/rating-star`
* [ ] `jetpack/recurring-payments`
* [x] `jetpack/repeat-visitor` (https://github.com/Automattic/jetpack/pull/19985)
* [ ] `jetpack/revue`
* [ ] `jetpack/simple-payments`
* [ ] `jetpack/slideshow`
* [ ] `jetpack/story` (https://github.com/Automattic/jetpack/pull/19876)
* [ ] `jetpack/tiled-gallery`
* [ ] `jetpack/wordads`

Note: For the Jetpack Contact Form, [tests already exist](https://github.com/Automattic/jetpack/blob/5a27b8ae1a760c0098067ddc152ac0879b9a2a91/projects/plugins/jetpack/tests/php/modules/contact-form/test-class.grunion-contact-form.php) — before working on it, check to see whether or not the existing tests provide adequate coverage. We might not need to fixture tests for this one if the existing tests suffice.

Start with test/php/extensions/blocks/test-repeat-visitor.php and the parent Jetpack_Block_Fixture_TestCase, then review the existing test_server_side_rendering_based_on_serialized_fixtures tests and serialized block fixtures. Choose an unchecked block, add its fixture test with any required state or mocks, and run the relevant PHP tests. Done means server-rendered fixtures are generated and checked, including deprecated markup where applicable.

Written by the indexing model from the issue text.