Reorganize the x-common files

[kytrinyx]

At the moment all of the files are in the root directory, and this is getting pretty unweildy.

I'd like to suggest that we move to the following structure:

.
.
└── exercises
    ├── bob
    │   ├── canonical-data.json
    │   ├── description.md
    │   └── metadata.yaml
    ├── clock
    │   ├── canonical-data.json
    │   ├── description.md
    │   └── metadata.yaml
    └── ... etc ...

This will allow us to have additional files for any of the problems, should we wish to do so (e.g. some way of deprecating the problem).

This will, however, cause a bit of extra work:

• Any generators that use the :slug.json to create the test suite will need to be adjusted.
• The x-api (problems API) will need to look for the metadata files in the new location.
• If we have other tools that use the metadata directly from x-common rather than going through the x-api, then we'll need to update those as well. I can't think of any.

[ErikSchierboom]

I love the idea of grouping everything related to an exercise in one directory. You could consider creating separate directories for current and deprecated exercises. Something like this:

.
└── exercises
    ├── current
    │   ├── bob
    │   │   ├── data.json
    │   │   ├── description.md
    │   │   └── metadata.yaml
    │   └── ... etc ...
    └── deprecated
          ├── clock
          │   ├── data.json
          │   ├── description.md
          │   └── metadata.yaml
          └── ... etc ...

That would make it easier to quickly see the difference between current and deprecated exercises, as well as make the parsing a bit simpler.

[kytrinyx]

Separate directories would make it easier to see/view/manage, but parsing might get more complicated since we'll have to look in two places as long as there are language tracks that have deprecated exercises.

[ErikSchierboom]

@kytrinyx Good point.

[Insti]

Can/Should this be done on a problem-by-problem basis?
Whenever a problem is updated it is then moved to its own subdirectory.

Advantages:

• Only one problem should break at a time.
• As the tools get updated to fix those single breakages it will make the moving of future problems easier.
• Doesn't require simultaneous co-ordination among all language tracks.
• Less work at any one point.

Disadvantages:

• Requires management of multiple possible problem locations while transition is in progress.
• Will probably cause many minor breakages.

[kytrinyx]

We can do this without breaking anything by making the API handle both cases, deploying that, and then moving all of the problems at once.

It will break the generators, but that only affects ruby and go at the moment.

[ErikSchierboom]

@kytrinyx I'll start working on a PR for the new format.

[Insti]

@ErikSchierboom, @ramyaravindranath might already be working on this as part of the RGSOC

[ErikSchierboom]

@ramyaravindranath Is that correct?

[ErikSchierboom]

@Insti @ramyaravindranath @kytrinyx I was already almost finished, so I've decided to just submit the PR. If it turns out @ramyaravindranath was already working on it, I'll be happy to revert my PR.

[ramyaravindranath]

@ErikSchierboom I just started my analysis. Its alright if you have already finished 😄

[ErikSchierboom]

@ramyaravindranath Okay, thanks!

[kytrinyx]

@ramyaravindranath we're going to need all the work done in x-api, still, and you'll be able to test against this branch.