Support BreakingGround-DLC in instance faking

[DasSkelett]

Got a bit bigger than I thought.
(And it's getting bigger and bigger)

Changes

Important stuff first:
Console command for faking changed!
It is now ckan ksp fake <name> <path> <version> [--MakingHistory <version>] [--BreakingGround <version>]
instead of previous ckan ksp fake <name> <path> <version> [MakingHistoryVersion].
I think this is more future-proof.
I am going to try my luck adjusting KSP-CKAN/xKAN-meta_testing.

IDlcDetector:
I added string InstallPath(), it returns the install path relative to the GameDir, that means for example "GameData/SquadExpansion/Serenity".
Depending on how this idea of mine will be implemented (if at all), we might restructure the whole thing again. But I think this is the best solution for now, I'm open for feedback.

I added bool AllowedOnBaseVersion(KspVersion), it returns whether a DLC is allowed to be installed or faked on a given basegame version.

I added

string IdentifierBaseName { get; }
KspVersion ReleaseGameVersion { get; }

to allow accessing those two from outside the interface implementations.
I changed the two fields with these names inside StandardDlcDetectorBase to getter without setter (this effectively is like the readonly modificator before).

CloneFakeInstanceDialog:
The GUI CloneFakeInstanceDialog has been adjusted:

If Squad releases another 10 DLCs we might get out of space and need a new system, but for now it works.

FakeInstance():
FakeInstance() is now a transaction.
Before the DLC just wasn't faked if f.e. the KSP version was < 1.4.0.
This left the user in an unfavorable situation, he had to delete the new folder and run ckan ksp forget once and try again to include the DLC. now it's all or nothing.

FakeInstance() takes the DLCs that should be faked as Dictionary<IDlcDetector, KspVersion>. Future DLC releases shouldn't need a change in this fuction.

Also CopyDirectory() is now a real transaction that includes IO operations, if I understand stock .NET transactions right they don't include them, but using ChinhDo.Transactions with TxFileManager should fix this.
Correct me if I got something wrong there (or anywhere else too of course).

Fixes #2791

Oh yeah, #2749 needs another rebase ^^

[DasSkelett]

I see that the "bug" that DLCs weren't faked without error message was used in the validation scripts.
@techman83, you could link the xkcd again...

But I still believe that it should behave the new way.

We can use the ckan compare command to determine whether to fake a DLC or not in the scripts.
Right now it outputs a very human readable answer:
"1.1.0" is lower than "1.4.1".
but if we add another option (--machine-readable or so) to output -1, 0 or 1 it should be more usable.

[DasSkelett]

The scripts have a function versions_less_or_equal to do version comparisons.

That's cool, thanks!

[DasSkelett]

The shoe is on the other foot!

Darn it, feared this would happen ;)
Will take some days until I'm home again.

[DasSkelett]

'Merged' the PR, thanks.

[DasSkelett]

Another minor point, the name error ends with "--Done--" while the folder error ends with "--Error--". Looks like this is because Manager.HasInstance(installName) will return true thanks to the instance that's already using the name?

It's because I just forgot to put a return in that specific kraken catch, so the execution continues and yes, Manager.HasInstance() finally returns true.

[DasSkelett]

Okay, some more changes:

• Added new kraken: WrongKspVersionKraken, to be used if a given KSP version is valid, but not allowed for an action (like instance faking and older base game version).
• Renamed IncorrectKspVersionKraken to BadKspVersionKraken to better distinct it from the new one. To be used if a version is not valid, i.e. not in the build map or malformatted.
• Added another test to check if FakeInstance() throws WrongKspVersionkraken for base game versions that are too old for the DLC(s) requested to fake.
• Redid the exit code handling in Cmdline.KSP.FakeNewInstance() a bit.

[DasSkelett]

Does the bot skip network-dependent tests?

[HebaruSan]

I believe so:

CKAN/.travis.yml

Line 43 in 1ac6261

- ./build test+only --configuration=$BUILD_CONFIGURATION --where="cat!=FlakyNetwork"

[DasSkelett]

Yep, just discovered that flag. Was wondering, because on my machine I obviously fail the two Curseforge tests.