Set feature_category for Geo specs

What does this MR do and why?

Describe in detail what your merge request does and why.

I keep seeing these and doing these myself in other work. Let's avoid wasting time.

Defines feature_category: :geo_replication on specs which are obviously owned by Geo based on file path.

Methodology

1. Added feature_category: :geo_replication to all paths containing the word geo in .rubocop_todo/rspec/missing_feature_category.yml:

   require 'yaml'
   todos = YAML.load_file('/Users/mkozonogitlab/Developer/gdk/gitlab/.rubocop_todo/rspec/missing_feature_category.yml');1
   geo_file_paths = todos["RSpec/MissingFeatureCategory"]["Exclude"].select { |path| path =~ %r{geo} };1
   geo_file_paths.each { |path| content = File.read(path); content.sub!(" do\n", ", feature_category: :geo_replication do\n"); File.write(path, content) };1

2. Deleted lines containing geo in .rubocop_todo/rspec/missing_feature_category.yml with find and replace - .*geo.*\n with nothing.

3. Manually fixed Layout/LineLength violations in a bunch of them. I think the single indentation looks weird, but it is enforced by yet another cop Layout/ArgumentAlignment. At least it is consistent, so I am sure I will get used to it.

4. Removed :geo tag when I fixed line length, since it is not needed anyway, because CI also categorizes specs as Geo if they are in a geo directory.

5. Manually added feature_category to ee/spec/finders/geo_node_finder_spec.rb (IDK why I needed to do this).

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.