Add RecoveryTester feature

[sebastianburckhardt]

This PR adds a new feature for testing the recovery of partitions without modifying any files in the storage account.

The feature is available in the form of a new option for the PartitionManagement setting:

   "PartitionManagement": "RecoveryTester",
   "PartitionManagementParameters": "7",

(specifying the partition is optional, if none is specified, all partitions are tested).

As part of this PR, I also

• refactored how partition managers are selected based on the PartitionManagement setting. This is in anticipation of adding a static partition manager setting, to replace the 'Scripted' setting.
• removed the 'Scripted' setting since this was meant for internal development only and I have not been using it and it for years, so it does not make sense to maintain that code.

[davidmrdavid]

A few first impressions.
Also - did you get a chance to test that read-only mode is in fact leaving a storage account as-is? We may want to try it out on a throwaway account first

[davidmrdavid]

From what I gather, this setting is rather dynamic, is it not? It can specify the partition ID if using the RecoverTester, but in the future it could specify other stuff (that's why the type is string), right?

I would prefer a more constrained/type-safe approach here, as I think parsing strings can get hairy over time. Could be create a proper options object?

[sebastianburckhardt]

Right, this is anticipating future, alternate partition managers where the parameter can be something much different (e.g. it could be an entire json object).

Could be create a proper options object?

Don't mind the idea but I am totally unsure whether/how that can work in the context of all the stuff the functions host does with host.json (e.g. magic environment variable settings and the like), and the stuff we are doing (copying parameters from AF specified parameters to Netherite parameters). So I was just taking the easy route.
If you have experience with it, let me know.

[davidmrdavid]

Gotcha. I do have some experience here (but not extensive) and I wanna say that the parsing will of host.json is an issue for the DF Extension, so I think that's a problem we can solve there instead of here. In general, it's not that magical :) .

In this case, yeah I think the ""right thing to do"" is to create a partitionManagement options class or interface with a subclass/implementation specific for the recoveryTester. That should suffice for us at this layer. I can solve the problem of parsing at the DF Extension layer :) . I can also commit to do a quick parsing test before merging

[sebastianburckhardt]

Got it. But for the sake of using our time wisely, I think it is still an o.k. solution to just use a string here. Can be refactored later to provide a more general solution if we really think it is worth the effort.

[davidmrdavid]

nit: I'm curious if we can mark this as obsolete to prevent future usage.

Suggested change

	/// <summary>
	/// Follow a predefined partition management script. This is meant to be used for testing and benchmarking scenarios.
	/// This was an internal feature and is no longer supported.
	/// </summary>
	Scripted,
	/// <summary>
	/// Follow a predefined partition management script. This is meant to be used for testing and benchmarking scenarios.
	/// This was an internal feature and is no longer supported.
	/// </summary>
	[Obsolete]
	Scripted,

[sebastianburckhardt]

marking it as obsolete may violates major-minor version change rules. I was trying to stay below the radar of the version-police :)

[davidmrdavid]

For this one, I feel like it wouldn't trigger the semVer police since this just raises a warning, not a functional failure. But I won't insist / don't feel strongly.

[sebastianburckhardt]

Also - did you get a chance to test that read-only mode is in fact leaving a storage account as-is?

I did some testing but did not actually look at storage afterwards to confirm it is unmodified. Can do that.

[sebastianburckhardt]

@davidmrdavid, are you o.k. with merging this PR now? I think the recovery feature has proved useful and there seems little risk with putting this in the main branch.