Dead code removal

[johnsimons]

Two unrelated pieces of long dead code, both on the Raven/recoverability side.

FindClrType

DatabaseConfiguration.FindClrType (audit) and
EmbeddedDatabaseConfiguration.FindClrType (shared ServiceControl.RavenDB)
were never assigned anywhere. Neither had a constructor parameter feeding it,
and no caller set the init property, so the delegate was permanently null and
all three consumers were no-op null checks.

Removed:

• the two properties and their now unused Sparrow.Json usings
• the if (configuration.FindClrType != null) blocks in
  RavenExternalPersistenceLifecycle (audit) and EmbeddedDatabase.Connect
• the object initializer in the audit RavenEmbeddedPersistenceLifecycle

The error instance had no copy of its own but shares EmbeddedDatabase and
EmbeddedDatabaseConfiguration, so it is covered by the same change. A repo
wide grep for FindClrType and BlittableJsonReaderObject now returns nothing.

Legacy retry batch guards

RetryingManager had eight copies of:

if (requestId == null) //legacy support for batches created before operations were introduced
{
    return;
}

added in fb328c1 (Dec 2016, shipped in 1.30.0) for RetryBatch documents
written by 1.29 and earlier, before retry operations existed. For one to fire
today, a database would need an in flight batch document written by 1.29 that
survived to 6.19 and the RavenDB 3.5 to 5 to 6 migrations without ever being
staged and forwarded.

Every path into the manager supplies a non-null requestId:

Source	Value	Guarded by
StartRetryForSingleMessage	uniqueMessageId	route {failedMessageId:required:minlength(1)}
StartRetryForMessageSelection	DeterministicGuid.MakeId(...)	computed
RetryForAllMessages	"All"	constant
RetryForEndpoint	endpoint	!string.IsNullOrWhiteSpace(message.Endpoint)
RetryForFailedQueueAddress	queueAddress	route {queueAddress:required:minlength(1)}
RetryForFailureGroup	groupId	route {groupId:required:minlength(1)}

The paths that read RequestId back out of persistence (Skip, Forwarding,
ForwardedBatch in RetryProcessor, Fail in RetryDocumentManager) only see
values that CreateBatch wrote from that same set. Two existing signals agree:
RetryDocumentManager.RebuildRetryOperationState already wrapped its call in a
!string.IsNullOrWhiteSpace check, and the EF persister declares
required string RequestId with .IsRequired() and nullable: false.

Why a throw replaces them

Deleting the guards with nothing in their place would not surface a null.
MakeOperationId interpolates, so null becomes the key "<RetryType>/",
GetOrCreate creates an InMemoryRetry with a null RequestId, and every such
batch collides on that one key while raising domain events with RequestId = null. That is quieter and worse than the old no-op, so GetOrCreate now calls
ArgumentException.ThrowIfNullOrWhiteSpace(requestId). All eight methods route
through it, so one line replaces eight guards at the exact point a null would
otherwise become a bogus dictionary key.

IsOperationInProgressFor and GetStatusForRetryOperation are unchanged: they
are read only TryGetValue lookups that never had a guard.

Behaviour change

Previously a legacy batch would still be forwarded, just without progress
tracking. It will now throw. Given the reachability analysis above this is the
intended trade: fail loudly on a state that cannot legitimately occur.