Move hosted files and rules to ids/ directory.

[davidlehn]

DO NOT MERGE

• The number of files and directories is too large for the GitHub web interface to display.
• It's difficult to find basic info on the GitHub project page with so many files.
• Hosted and non-hosted files were mixed together.
• Even this PR is hard to view on GitHub with so many renamed files.
• This PR takes special care to merge. The production environment needs adjusting for the new hosted file locations. @davidlehn will handle it.

Closes: #2709

[hoijui]

Maybe you did that, or it makes no sense in this case, but I though I mention this idea:
For similar changes, I usually write a (BASH-)script that does the moving/renaming, and commit it. This script can then be applied to the primary branch, and then later also individually to any other branch (for example outstanding PRs or local branches that were dormant for a while), before merging back into the primary branch. This somehow documents the change, and also prevents some merge-conflict scenarios.
Because the script is usually small, it does not clutter the history much, even if it is surely going to be removed at some later point.

[davidlehn]

@hoijui I'm not sure I understand. How would a script help here? I think writing a correct script and instructing people to use it may be more difficult then using git itself to do the updates. I think the git part will be challenge enough. A script also won't help the many people who, I think, are only using the github UI to make changes.

[davidlehn]

This has been open for a significant amount of time with little feedback. At some point this PR will be updated and applied if no one objects.

[hoijui]

The script helps primarily people like you, who might maintain different branches, or who would apply the script to branches by others, which branched off before this change, and which we want to merge back after this change.
The question is mainly, how many such branches/forks are expected. A good first guess is the number of open pull requests, though in the case of this project, there might be many more, half-dormant/half ready commits/PRs in the making.
It was just a though anyway. I know for certain that it can be useful, but it depends a lot on the nature of the change and how many people are maintaining and what not, so I do not want to suggest it is meaningful in this case. If you think it is not, it probably isn't.

Hope you get this change through soon! :-)

[bact]

Great initiative and I support this. Thanks for the work.

I guess we also need an advanced announcement as well that we are going to freeze the repo for few days in order to make this change (and avoid merge conflicts).

1. Announce the intended freeze period
2. Stop merging other PRs
3. Solve merge conflicts for this PR
4. Merge this PR
5. Announce the unfreeze

[davidlehn]

I guess we also need an advanced announcement as well that we are going to freeze the repo for few days in order to make this change (and avoid merge conflicts).
[...]

There's really nowhere to make announcements with this service. This ids/ update is not a days long process. I think I only spent no more than 30 minutes on this PR. Fixing it or doing it again will be quick. Updating the live servers the easy way will mean a minute or two of downtime to adjust some things. Could make that almost zero downtime but that's more effort than it's worth. Then the few open PRs here will likely need fixing. We'll have to watch new PRs to make sure they use the new pattern, but if old style ones are merged, they won't work, so that should resolve itself quickly.