drop eol jira support < 9.12.0

[Joris29]

Pull Request (PR) description

Drop eol jira support < 9.12.0

[bastelfreak]

@SimonHoenscheid can you have a look?

[kenyon]

Copy of my comment from #474 because it's really about this PR: I wonder if it would it be better to put the hiera data in the module's code or as hiera data in the module, if these data are needed to make the module work.

[Joris29]

@kenyon For me it's kinda of a no go.
I'll try to keep my opinion on this simple.
While java is a requirement for jira itself i don't think this jira module should have a hard requirement on java that's why java_package is optional, a user should still have the freedom to choose whether to install it manually with the java module or with this module as a package resource.
For javahome that's something else this should not be optional and isn't really optional either because in the code this is checked: if $javahome == undef { fail('You need to specify a value for javahome') }

[kenyon]

@Joris29 usually our modules have class parameters to disable management of things such as Java packages. I'm just thinking about how to make a working setup by default with minimal configuration, such as just by doing include jira. But I leave it up to you, since I'm not using this module yet (and at the rate of progress we're making, we'll probably be migrating to a cloud-hosted Jira before we get migrated to this module (and it seems that pretty much everyone will be cloud-hosted by 2029 due to EOL)).

[Joris29]

@kenyon It's also kinda present in this module because if you set a java_package it will use the package resource otherwise it won't.
About just include jira this is not really possible at the moment anyway as the default db is postgresql which requires some additional setup/config as well and i don't think you want to enforce this in the jira module.

[Joris29]

@SimonHoenscheid Any thoughts on this?
On the release PR a comment was maybe that it should cover jira >=11 (#471 (comment))