Formatting changes from codegen

[rattrayalex-stripe]

I don't think this will be quiiite the last PR of this nature, but this should be the main chunk of work and should probably be reviewed by itself.

Primary categories of changes here:

1. Ignoring the new line-length rubocop in the directory with the codegen output.
2. Pulling the object_classes map and resources requires out into their own files, so they can be more easily codegen'd (though I have not yet implemented this).
3. Reordering include/excludes. TBH I think this ordering is worse, I hope to make it better later. Let me know if you think it's worth investing in now.
4. Reordering methods – mostly, things that are codegen'd come first, then things that are hardcoded.
5. Whitespace changes
6. Moving comments around for convenience
7. Going from initialize_from to Util.convert_to_stripe_object in most cases – I think this was something you recommended a while ago

r? @ob-stripe

[ob-stripe]

LGTM minus one comment. Will ask @brandur-stripe to take a look too just in case.

[ob-stripe]

ptal @brandur-stripe

[brandur-stripe]

Left a few comments, but looks mostly good to me as well!

ptal @rattrayalex-stripe

[rattrayalex-stripe]

Okay, updated to incorporate feedback, and to move resources into their own dir

[rattrayalex-stripe]

oops, forgot to
r? @brandur-stripe

[brandur-stripe]

Thanks Alex! LGTM.

[AnotherJoSmith]

@brandonl-stripe @rattrayalex-stripe There seems to have been a pretty important change in this PR in ea736eb.

Previously when calling any of the methods that used initialize_from, the instance you called the method on would be mutated. When changed to Util. convert_to_stripe_object, we instead return a new instance of the object. This has broken some of our code with PaymentIntents where we would directly return the result of payment_intent.cancel or payment_intent.capture.

If this change in behaviour is intentional, it might be worth it to add it retroactively to the changelog, since it can easily introduce subtle bugs in people's integrations if they're not handling the return values of those methods and are instead expecting the instance to be mutated with the result of the API operation (which is a reasonable expectation IMO).

[rattrayalex-stripe]

Thank you very much for reporting @AnotherJoSmith – that was not an intentional change! Thanks very much for reporting. I'll sync with the team on where to go from here.

[rattrayalex-stripe]

Alright, #806 should resolve this. I have some work towards a nicer / longer fix on another branch.

Feedback welcome there!

[rattrayalex-stripe]

@AnotherJoSmith Sorry for the delayed release – the fix is out in 4.21.2.

[AnotherJoSmith]

Thanks Alex!