Support custom subject text

[czy-29]

Close #230

[Enet4]

The feature works nicely in the general case. I did notice that there are no constraints to the subject content in terms of length and characters. Considering that any client can request these on the spot, it might be for the best that we add some safeguards (e.g. 100 maximum length).

Also, subject is ignored if style is given an unsupported value.

[czy-29]

The feature works nicely in the general case. I did notice that there are no constraints to the subject content in terms of length and characters. Considering that any client can request these on the spot, it might be for the best that we add some safeguards (e.g. 100 maximum length).

What do you think we should do when the length exceeds the limit? Should we treat it as if there is no subject parameter?

[czy-29]

Also, subject is ignored if style is given an unsupported value.

As for this issue, it seems to be an existing bug. Consider the following two requests:

• https://deps.rs/crate/syn/2.0.66/status.svg?style=for-the-badge&compact=invalid
• https://deps.rs/crate/syn/2.0.66/status.svg?style=invalid&compact=true

They each have one parameter that is invalid, but neither of them responds to the other valid parameter.
The root of this problem seems to be that we can't simply get the extra_config through: serde_urlencoded::from_str::<ExtraConfigPartial>(qs).
We need to think about how to fix this.

[czy-29]

@Enet4
All the bugs have been gracefully fixed! The relevant rationales are written in the code comments.
The fix was a bit trickier than expected, but eventually I managed to find a graceful solution.
Looking forward to your review!

[czy-29]

@Enet4 Hello, two months have passed, can we merge this PR?

[robjtede]

the same concept as label in shields.io,

is there any reason not to match the naming ?

[czy-29]

@robjtede Thanks for the review! I will make changes and reply tomorrow!

[czy-29]

the same concept as label in shields.io,

is there any reason not to match the naming ?

This is because we have been using the term subject instead of label for this concept in our internal code before. If we switch to label, it means overturning all the variable names in the previous code. I'm not sure if this is a good idea. Of course, exposing previous naming to the public can also cause confusion for users, so this is a trade-off, and I am not sure which option is better.

[czy-29]

@robjtede All modifications have been completed, waiting for your final decision on whether to use subject or label, and looking forward to your review!

[robjtede]

i don't mind too much about the label, would be easy enough to add an alias later

[robjtede]

thanks for your work on this 👍🏻